The Kiss Principle
The last two decades have seen software development become an integral part of every industry and every aspect of a day to day life. That has also meant that the sophistication of the software being developed is becoming increasingly more. These days very few software are built from scratch, but rather are built on top of existing frameworks and the motto usually is Rapid Application Development.
Given the fact that the software these days are huge and enormous depending on multiple libraries, frameworks and communicate with other applications, the complexity of these applications is pretty high. Other traditional issues like scope creep, feature creep and code bloating just make the situation very difficult.
What complicates matters is the fact that complexity analysis is still at a very nascent stage. Currently available tools look for things such as the number of loops, number of lines, and number of conditions to determine the complexity of software, but do these really give the correct picture of a complexity of software. For e.g. if a function has 4 possible condition checks; is that more complex than four functions each having one condition check with one additional function to invoke them in sequence?
At this moment, let’s revisit an age old philosophy called the KISS principle. Before you start letting your imaginations run wild, let me clarify that KISS stands for “Keep it Simple & Stupid”. This acronym was first coined by Kelly Johnson, who once set a challenge for his team developing Jet aircraft. He handed his design engineers a handful of tools generally available with an average mechanic with the instruction that their design for the aircraft should be repairable with only these tools under combat situations. The key concept of this is that the design simplicity should be a key goal and the unnecessary complexity should be avoided. The major benefit of this approach is that the design is understood well by all team members and the maintainability of the software is also high.
- As a Technical Lead/Architect if team members find it difficult to understand the architecture or design, it is time to re-think the architecture rather than questioning their intellect.
Two tendencies in developers are the biggest road block to achieve the KISS principle. The first tendency is called the “Second System Effect” (first coined by Fred Brooks in “The Mythical Man Month”) which alludes to an attempt to recreate a small, elegant solution and then adding unnecessary grandiose around it, thus killing the elegance of the solution in the first place. Some times this is very obvious, when the famous “re-inventing of the wheel” is detected, but more often than not, this is missed. Tell-tale signs of this tendency are when people start writing wrappers over APIs and try to bundle it with their existing applications. This makes the overall application bulky as well as creating unnecessary complexity in the whole system.
- Are there too many wrappers in the project, time to re-think the strategy?
The second tendency is the more common one called as the “Creeping featurism” or as some now refer to it as a disease called as “Creeping Featuritis”. This is the systematic loading of new features onto an existing system and there by slowly but surely killing off all elegance to the original software. A simple example that comes to the mind is the BSD Unix or the legendary “ls” command in UNIX. As this happens gradually over time, it is often difficult to detect.
- Over time if the founding principles and the design values are no longer true, then it is again time to re-think.
So how do developers working on huge projects with many layers of complexity built into the system incorporate the KISS principle as they move forward? That in today’s world will be the key to success, especially in a world where productivity is now a constant demand from the customers. Another old principle called the Occam’s razor (or Ockham’s razor) could be the solution you are looking for. This will be covered in the second part of this article.
Ram Narayanan Sastry