Simplicity Is Over Rated

Over and over again I see the advice, in one form or another, of "make it simple". XP proselytizing has skyrocketed this slogan into some top ten list. I have been thinking that simplicity is a quality without meaning.

In interviews I always ask what are your greatest programming insights? If I get an answer at all it is usually "keep it simple". A follow up is "how do you do that?" Almost no one has an answer. Another follow up is "how do you know when you see it?" Almost no one has an answer.

Please refactor. Refactoring trades a local simplicity with a more global complexity if zillions of little interconnected methods.

I can just see someone saying the human body is way too complex. Please refactor. (Or see OrganicSimplicity.)

"Keep it simple" does not mean "Make complex things simple".

It has a specific and restricted meaning, i.e., "add no unnecessary complexity".

How to keep things simple :

Start with something simple: A unit test for code that doesn't yet exist is as simple as you can get.
Next, don't make it complex: A good way is to only write code that will satisfy the unit test you just wrote.
Finally, make it simple when you have inadvertently made it complex: That's where refactoring comes in.

This is just KISS stated a different way. In other words, it's not helpful. The KissPrinciple merely asserts that simplicity must be kept (and calls the reader stupid), these three instructions tell us how to obtain and retain simplicity (and assumes that we aren't too stupid to achieve this). Big difference)

The principle is self-applicable : your criterion for determining what is simple and what is too complex should be simple. PairProgramming provides a simple criterion. If the programmer next to you can't understand a method at a single glance, it's too complex. If she can't understand a class after a few minutes, the class is too complex. If she can't understand the whole system after explaining its metaphor over lunch, the system is too complex.

This assumes that the programmer in question is familiar with the problem domain, and therefore has a good enough grasp of its EssentialComplexity; "keep it simple" rejects unnecessary complexity, not EssentialComplexity.

OccamsRazor

Code is simple when, upon examining a method, one finds it to be as expected. The easy way to achieve simplicity is to be clear as to the nature of the problem being solved and to solve only that. New insights are included in code through refactoring. There. Do I get the job?

Note: "keep it simple" is poor advice because it offers no hint as to how to proceed. However, ExtremeProgramming's practices are good advice because they are easy to follow and lead to simple solutions.

Hint: Complex system is simple one when it is not ConfusingSystem?.

"At what scale is the solution simple? I installed CppUnit so we could have a common unit test infrastructure. I let people know it was there. Now as a subsystems go CppUnit is extremely simple. Look at most methods and they are simple. Out of 4 people who tried none of them could figure out how to use CppUnit without help. In general they were not stupid people. Isn't CppUnit supposed to be a good example of extreme programming code? How could CppUnit be said to be simple is people can't figure out how to use it?"

Re: Code is simple when, upon examining a method, one finds it to be as expected.

An EverythingIsRelative viewpoint may be that what is "expected" depends on the individual. I find my code simpler than others' because I know my style and why I do what I do. However, even within the realm of my own code, some designs turn out simpler than others (at least to me). I find that usually this happens when there is an impedment to making it fit the problem closer. For example, the limits of the HTTP protocol and HTML-based browsers often require doing odd work-arounds that would not be needed for a "real" GUI environment. It is difficult to make a simple framework to hide the limits, which at times seem unhidable because they are hard-wired into web standards.

Perhaps SimplicityIsOverRated only if it is not achievable within a reasonable effort. For example, to achieve the simplicity that HTTP/HTML/JS seems to remove may require a complete overhaul of standards. Thus, it cannot be removed with "reasonable effort" for a single shop, and therefore must be lived with.

KeepItSimpleStupid has discussion about the virtues of simplicity.

Another way of describing these thoughts is the dangers of under simplifying

What are the dangers of over simplifying ?

over simplifications have marginal or short term utility.

OccamsRazor

If it is the case that simplicity is overrated, then ....

It's not that simplicity is overrated its that complexity is pugnacious and comes without warning. Worse yet, complexity is emergent. It creeps up on a system. I think there are two basic ways to keep something simple:

Make it as simple as possible to model a problem
Make the model of a problem as simple as possible

The first makes it easier on the programmer to represent a problem (or its solution) in code. It concentrates on making the mapping between the problem as solution as simple as possible. The second concentrates on making the actual solution the most simple representation of the problem. In the second case, the mapping between a very complex problem and a very simple solution may be quite difficult. However, the problem with the first case is that a complex problem will always result in a very complex solution. Why? Because we are taking the most simply approach to modeling the problem instead of looking for the simplest model of the problem. It is not easy nor is it always simple to find the most simple model of a complex problem or solution. Consider a very complex algorithm your program needs and you can only find procedural examples of it. The easiest way to implement this, the simplest approach is to take the procedural algorithm and simply cram it into a very large method. This does nothing to actually simplify the problem, instead it is the approach to coding the problem that is simplified. So, for myself, when I hear DoTheSimplestThingThatCouldPossiblyWork, I view it differently -- I view it as the second case. To make the simplest model of the problem as I can. Unfortunately, making something simple is often not the simplest approach. My position is that taking the simplest approach often results in the complicated solutions (or code-representations of a solution) that are difficult to comprehend. As many others have said much better than me, "simple isn't easy". -- RobertDiFalco

I would suggest 3rd option: 3. Try to simplify the problem.

It is most difficult and very useful option. �Problem� is considered being carved in stone, in some cases it is not. It is about a situation when customer has overcomplicated business processes, which make computer-based solution more harmful than useful.

In many ways this is like the ethos of the UnixOperatingSystem. Rather than creating an AllConsumingApplication?, the means to use lots of smaller and more specific tools together is preferred. Now I think about it, this is also like the (unfortunately) obsolete OpenDoc model from AppleComputer. I believe MicroSoft had a similar idea too. The idea was that one bought OpenDocModules? which might be a SpreadSheet or a SpellChecker and added them together to create precisely the "Application" you wanted. (In reality it was not an executable program - there was no Quit). The advantages are obvious, smaller, lighter, cheaper programs. Unfortunately, for one reason of another (I personally lost track of it) it was discontinued. -- MatthewTheobalds

If it is not the case that simplicity is overrated, then ...

In the MythicalManMonth, FredBrooks says something about accidental and EssentialComplexity (I think he quotes someone else, but I cannot recall who it is). His point is that what we do with computers is inherently complicated - and that we shouldn't add AccidentalComplexity. -- OleAndersen

''In interviews I always ask what are your greatest programming insights? If I get an answer at all it is usually keep it simple. A follow up is how do you do that?''

My answer is to compare the cost of doing something with the value of accomplishing it. I usually find when someone is spinning their wheels, he is often caught up in trying to add a "neat" additional option. I have seen far too many cases where features strongly desired by the user were delayed while unrequested gizmos were being debugged. A final philosophy is that it is easier to add desired functionality than to remove unneeded functionality.

--WayneMack

One guideline for achieving simplicity is to avoid special cases. Especially in interfaces - it can be worth making one module more complex if all the other modules which use it become simpler (ie have to deal with fewer special cases). This is a form of OnceAndOnlyOnce - the special cases are handled in just one place.

To eliminate special cases, think about what they have in common. Find an abstraction that they can all conform to. This is difficult because it is pattern recognition. Some tricks for approaching it include: restate the problem in different words; compare with problems already solved; personify elements of the problem; parameterise. Try reading Polya's HowToSolveIt for more.

See KissPrinciple DoTheSimplestThingThatCouldPossiblyWork OnceAndOnlyOnce AccidentalComplexity EssentialComplexity OrganicSimplicity DoSimpleThings

For a definition of simple, see SimplestOrEasiest.

Simplicity is a measure which can made at programming and user levels.

"The natural tendency in human languages is to keep overall complexity about equivalent, both from one language to the next, and over time as a language changes. Like a waterbed, if you push down the complexity in one part of the language, it increases complexity elsewhere." ... "Perl 6 grammars aren't simple. But they are complex at the language level in a way that allows simpler solutions at the user level." --- | Perl 6 Essentials (AllisonRandal?, DanSugalski? & LeopldTotsch?, ISBN 0596004990 O), pg 17.

What is it you want to keep simple? Keeping a user interface simple (usable) usually involves more complex code than the alternative. Keeping the code simple generally means passing the complexity on to the user--one reason not to let programmers design user interfaces. --mt

If A and B are two "systems" and A is simpler than B, then A can do simpler stuffs than B, but can at the same time do "more" stuffs. And probally faster.

Also, a complex system can be approximated by a set of simpler ones.

Wait! Are you really reading up to the third paragraph? --Gigi

WaterbedTheory

CategorySimplification