Reducing Software Complexity – II

The Ockham’s razor

In the first part of this article, we took a look at how the KISS principle helps in reducing the software complexity. But, 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.

Friar William of Ockham was a 14th century English logician who insisted on explaining any phenomenon with as little assumptions as possible and symbolically cutting off the rest of the assumptions with a Razor. The razor’s strict form, which prohibits irrelevant assumptions in a given theory, is justified by the fact that all assumptions introduce possibilities for error. If an assumption does not improve the accuracy of a theory, its only effect is to make the theory more error-prone, and since error is undesirable in any theory, unnecessary assumptions should be avoided.

When applied to software, it can be viewed as an incremental removal of complexity from a system. For example, suppose there is an assumption in a piece of code that an event would be fired and a handling mechanism has been put in place. But that basic assumption is not true anymore, then as per Occam’s razor, the handling mechanism is chopped off. While this example looks simplistic, this is not so often in real life as the software passes through multiple hands during its life-cycle and it is not almost evident why something is put in there. But, if it does not make sense to you, it is at least worth an investigation!! I have found this to be a very handy philosophy and if applied regularly and with proper analysis, it helps weeding off the bloat in the code slowly, but surely.

  • If the design or assumption does not make sense, it is worthwhile to invest some time to investigate this. Whether you like it or not, by making a small change you already own the complete piece of code.

The other aspect of the design is the ridiculous idea that knowledge of design patterns makes you a better designer. I have seen more applications spoiled by the wrong application of design patterns than those that have really been benefitted. The root cause for this is that design patterns are solutions for generic problems. Any generic solution is usually bloated to take care of various scenarios, but those might simply not be applicable to your project. Quite a few designers fail to grasp this concept and apply the design patterns verbatim into projects. In fact, in one of my previous projects, when I spoke to a designer why do we have this design pattern here, I got the answer “I wanted to try out the pattern”!! Though it is laughable now, but the fact is that designers do like to try out such things as they are perceived to indicate technical superiority and sometimes end up making things unnecessarily complex. One of the most often used quote with respect to generic design and one worth remembering is “Once they become “too general purpose” they become useless.” Remember those great libraries GTK, XLib, GNOME which simply bloated, thus bloating any application that used them.

  • Use design patterns or libraries to solve problems in your project and not to put the patterns and create problems instead.

  • If team spends more time troubleshooting technical aspects rather than concentrating on the business logic, alarm bells need to start ringing.

Finally, let me close this article with a famous story involving Sir Thomas Alva Edison. Once, Edison put a young engineer to test by asking him to determine the volume of an irregular vessel. After several hours of hard work, the engineer triumphantly produced his calculations and asked Edison to verify. Edison simply filled the vessel to the brim with water and poured this water into the measure can and came up with the volume. The whole process took him 5 – 10 minutes of effort.

So in whose shoes are we in today – The young enthusiastic engineer or the smart and simple Edison!!

Morals of the Story

“It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint Exupéry

“Simplicity is the ultimate sophistication” – Leonardo Da Vinci

“Everything should be made as simple as possible, but no simpler” – Albert Einstein




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s