The last principle in the Red Degree is the also the one that I struggle the most with. Keep it simple Stupid (KISS) is an old saying and it is good advice in a number of situations. It basically says that when you have two solutions, the simplest one is preferred.
The reason that I struggle with this rule is probably pretty common. Like most software developers I like complicated problems. If I find myself working on something boring and mundane I will frequently try and find a way to make it more interesting by finding an “elegant” or “efficient” or “reusable” solution. Note that I put quotation marks around elegant, efficient and re-usable because they are just the excuses that I use to justify my actions.
The reality is that the client shouldn’t have to pay for a solution that does anything more than solve their needs. If the client wants a website that they can use to edit a table or two in a database then they shouldn’t have to pay extra just because the system is designed to allow the developer to easily swap out the database for an XML file or change the interface to an integrated Outlook plug-in.
You may think (as I have been prone to) that making the system more flexible will result in a system that is easier to maintain. In fact, usually the opposite is true. If it will take more than a glance for a maintenance programmer to understand how all of the pieces fit together and where potential problems might lie then you are costing the client again. If a maintenance developer needs to hunt you down and ask questions then you are costing the client even more.
Having said all of that Albert Einstein once said “Everything should be made as simple as possible, but not simpler.” There are reasons for complexity. Sometimes it DOES actually add to the maintainability of the solution. If new features can be added very quickly by leveraging existing code then the business gains an advantage in software flexibility. Sometimes it CAN make a solution more readable by abstracting away unnecessary details. Good naming conventions go a very long way towards this goal.
KISS can conflict with DRY in a surprising number of ways. After all, if you have multiple classes with the same method in them then DRY says you should extract a common base-class for them (or find some other way to prevent the duplication). It is debatable but I’d say that is moving away from the simplest solution and towards a more complex one. Now someone trying to understand the code needs to look in two places to understand each concept but they need make only one change to affect multiple concepts.
In order to try and control your urges to “make it more interesting” you can employ frequent Code Reviews. If asked to perform a Code Review try to get as much information from the code in a few seconds as you can. If you can’t explain what is going on at a glance there may be an issue (or you may be dealing with a particularly complex problem). The most frequent form of Code Review that you can do is to practice Pair Programming.
One of my favourite articles to address KISS and the developers tendencies to violate this principle is Programming Sucks! Or At Least, It Ought To by Alex Papadimoulis. I’ll leave you with the final paragraph from that article which is a nice sobering thought:
At the end of the day, the best programmers are not the ones that create the most beautifully-elegant, exceedingly-innovative code. The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs. And those are the type we should all strive to be.
No new comments are allowed on this post.