We all know the importance of good clean code. Meaningful names, ubiquitous language, one level of abstraction per function, SRP, OCP etc etc. It is not debatable that good code would lead to better reuse, maintenance, enhancements etc etc.
Have you ever encountered the scenario where the code was too good and that was an issue?
I was reading the book, The Pragmatic Programmer: From Journeyman to Master a few days back when I realized that very well written code could also be an issue as it becomes difficult to change. People are reluctant to change something which is deemed to be perfect. Would you dare to change MonaLisa?
Reflecting back on a project I remembered that there was a multi threaded module which used to parse and process tax statements and report validation errors. This module was a part in the chain of systems where there were 20 other modules. This module was so well written using the required design concepts, OO concepts that whenever the developers felt the need to change it, they would step back and make changes in another part of the chain. Since it was a perfect system there was a lot of time spent on developing it too. On an average the construction of this module tool 2.3x more time than other modules of the same complexity. Developers were afraid that touching this system would destroy the beauty and perfection with which the system was made.
Drawing an analogy, I have 2 credit cards. One has a limit of x and other has a limit of 7x. You would be correct if you guessed that I use the first one more often, well almost always for all my transactions at the stores and online. I have used the other one only once when I was stuck in SFO and had to catch a flight to New Jersey. The first card has been good enough for me in most of the situations. I am reluctant / hesitant to use the other one since I do not want to expose the card # of the higher limit one to the world lest hells break loose and the # becomes available all over the internet. I am sure I am not the only one who thinks this way.
The same holds true for Code Quality. While you can be perfect but good enough code would see you through 99% of your scenarios. Again, do not get me wrong. Good Enough != Bad Quality. It is still very good except that it is 95% of Perfection. The time spent on getting that extra 5% is sometimes > 40% of the time spent on getting to 95% quality.
Agile propagates the same concept when it talks about, “Release early, release often”. While you might be tempted to be perfect but in most situations it follows the law of diminishing returns. As some wise men said “Perfect is the enemy of Good Enough”
All right, back to writing some good enough code which my colleagues would not be reluctant to change.
