Simplify and Add More Lightness

My immediate family has a preponderance of engineers, not software engineers but the old fashioned kind that build physical objects. I always find it enlightening to observe the similarities and differences between classical engineering disciplines and software engineering.

One dictum that has come down to me that I always follow, 'Simplify and Add More Lightness'. My father applied it when designing racing cars, my sister a trained engineer applies it in her chosen engineering discipline - dressmaking (just think about it).

So what are the ramifications?

Primarily it means, as the XP programmers have it, that a piece of software should only be as complex as it needs to be to do the job and no more. I agree whole-heartedly that the avoidance of abstractions, neat tricks and anything that obscures the intent of code is to be avoided. The problem is that, despite whatever the sellers of methodologies tell you, there is no substitute for experience in determining how complex a piece of software needs to be.

I have a few questions that I use to make this judgement call:

• What are the invariants of a system? An often difficult question to ask, but rewarding. The invariants are the parts of the system that should have the fewest or even no abstractions. They can be certain key business objects and behaviours, certain work flows or even the fact that communication between components is to be asynchronous or synchronous. I tend to use these invariants to define the skeleton of systems that I am designing and they throw into stark relief the next question.


• How fluid are the variant elements of a system? An equally difficult question to ask. The degree of fluidity helps one to decide which level of abstraction to define. If something is unlikely to change during the lifetime of the system, then maybe just an interface should be defined. If an element is likely to be changed several times perhaps a factory should be written. If the element is likely to vary continuously, then some form of declarative configuration should be used, whether an XML file or even an end user defined set of rules in a rules engine.


• What is the likely skill level of the support staff? A question that is not asked as often as it should be. If there is likely to be a high turnover of the support team, giving them little or no chance to learn the system, or there is likely to be a preponderance of junior staff then this question is vital. A compromise will often need to be reached between the efficiency and simplicity of a system. An efficient system sometimes uses sophisticated techniques to be performant, however it often leads to complexity which then has to be supported. It is worth remembering that the more complex a codebase, the more prone it is to bit-rot.

A second important ramification of this dictum is that a piece of software should be as 'light' on the system it is using as possible. With certain exceptions (see above), overly complex systems are not performant, if messages are flying backwards and forwards, the code tends to be tangled and to make inefficient use of resources.

A good physical example of the application of this dictum is that of a bicycle, the most invariant elements are the carriage of a person, pedal power and two wheels leading to the relative simplicity and inflexibility of a frame. The more fluid elements are direction, speed and incline. Direction is handled by a simple steering abstraction. Speed and incline require a much more complex abstraction, that of gearing. It is interesting to note that there is still room for valid variation in the design of the 'skeleton'of the bike (prone bicycles) but the frame remains a static structure.

In the early days of bicycles, they were designed to be maintainable by non-specialists, either blacksmiths or the cyclist themselves, and were thus extremely simple and made of basic materials such as iron. With the rise of cycle technicians, more sophisticated materials were used such as steel, aluminium and now composites; the gearing solutions became increasingly complex and now there is even non-essential complexity, suspension systems.

I always try to design systems to be as simple as possible, but I am sophisticated in how I do this.