Note. This is part of my posts covering "Golden Rules of Engineering".
This rule states, that simplicity has value on it's own. System should be designed to be as simple as possible, that satisfies all requirements. What we want is a system, that has as few moving parts as possible, so that it's structure is clear and well defined.
Simplicity brings many benefits:
- System is easier to understand by someone who has not designed it. Engineers have a habit of trying to prove their abilities to themselves by overly clever engineering and use of unnecessary amount of abstraction. This is not for the benefit of the system. Remember, your craft will be likely used and operated by many people after you. You want them to easily understand the workings of the system and get up to speed whether they're engineering, operating or fixing the system. And remember, sometimes the user after you is yourself, long after you've forgotten what you were thinking at the time you designed the thing (and let's face it, nobody likes documenting stuff).
- System's stability is generally inversely correlated with the level of it's complexity. Reducing the number of moving parts in the system also means lowering the interactions of the system's parts. A part might work just fine, but it's operations with other parts are not readily observed until the system has been in use for some time.
- Easier to fix. Having a system with clear structure and well defined, specialized parts converts to being easily tell in what part of the system the problem lies and what might be it's cause. "Complex systems break in complex ways." --Peter Neumann Problem in a system with complex structures might be hidden and might manifest itself with strange behavior that might not even be understood as a problem. Also finding it's cause is more difficult and fixing it takes more effort and time.
Applications of the 2nd rule in software engineering
Simplicity here does not mean lines of code, low level of abstraction or spartan approach to coding. Low amount of moving parts is a good indicator of simplicity and so is level of abstraction that can be justified for system's parts to remain well-defined and narrow in their scope.