Simplicity

A year ago today, I noted that someone had made a web slideshow of Edward de Bono’s principles of simplicity (from his book Simplicity). The site is no longer there, and The Wayback Machine only had some of its pages, but I found the list of principles after some googling:

1. You need to put a very high value on simplicity
2. You must be determined to seek simplicity
3. You need to understand the matter very well
4. You need to design alternatives and possibilities
5. You need to challenge and discard existing elements
6. You need to be prepared to start over again
7. You need to use concepts
8. You may need to break things down into smaller units
9. You need to be prepared to trade off other things for simplicity
10. You need to know for whose sake the simplicity is being designed

1 and 2 seem obvious, but simplicity is very often sacrificed at some stage in the project when the pressure rises; then the task of “cleaning things up” is deferred until “later,” and complexity accumulates.

3 is interesting. Sure, you must have a fairly good understanding of the problem domain, but with software there are two things to note here: first, the understanding of the problem domain, and of possible solutions, takes time to emerge – regardless of whether you spend months planning the system up front; second, software is soft – you can change existing code using refactoring, to make it simpler. You can even throw out parts and rewrite them.

4 to 6 is about feedback, about actually trying ideas to see if they will hold. To do this you must write code. Thinking about code and drawing diagrams representing code is very valuable, but the most effective way of learning whether something works is to actually write the code. The first solution you can think of may not be the best; spend a little time with a handful of possible solutions, to see what you learn. Refactor or rewrite that which doesn’t work.

7 and 8: using concepts is about abstraction, which lets you deal with complexity by ignoring all the details for the moment. Metaphorical abstraction can be even more effective. Breaking things apart is to me more about refining concepts, which might also be achieved by merging two concepts and forming a new, more intuitive and cohesive one.

9 is to me to be attentive to what an increase in complexity would mean, about trying to weigh the value of a feature with the complexity it would add to the system. This might be a tough call as the complexity is internal and the feature is external. It might be difficult to explain to non-programmers the effects of increased complexity. But it is important to find alternatives that can be implemented with less impact on complexity.

Lastly, 10 – the simplicity I am talking about is internal simplicity, so it’s simplicity for the sake of the programmers; the purpose is to design the system internally to be as easily understandable as possible, and to minimize the overhead in working with the further development of the system, so that one keeps increasing complexity from lowering the pace of progress too much. Now, complexity will increase during the course of the project, but it doesn’t have to increase more than is necessary to provide the features that are added incrementally. Complexity shouldn’t come from lack of time to maintain a simple design.

Simplicity isn’t an absolute. If the problem itself is complex, the design of the system can’t be too simple. It’s as if over-simplicity wraps around to complexity. An overly simple design is actually too complex.