Supposedly the band KISS used the acronym for the way that they constructed their songs. KISS stands for Keep It Simple Stupid. When applied to software development, the goal is to create applications that are easy to follow and maintain. On the surface, this sounds like something that would be easy to do when developing software. However, this is one of the most difficult principles to actually apply.
Not all developers fit this stereotype but most of us feel that learning new popular frameworks and software patterns are fun. It is also nice to show off what we have learned by applying it as quickly as possible in code. Sometimes there is a good fit between what is new and cool and a business need but not always. I have seen time and time again where a developer wants to learn a new framework/pattern/library and they throw it into the project, unnecessarily over complicating it. I am guilty of this myself. Since I have a lot of experience with regular expressions, I sometimes use them even when there is a more simple solution. Scott Hanselman has a saying, if you solve a problem with a regular expression, you now have two problems. As an architect it is also easy to get into a pattern of over architecting a solution, creating layers where none are required.
There was once a developer that I worked with that added a new front end framework to a solution. It was cool, it was slick; but it was nearly impossible to read the code. The people that came along later to maintain it could not understand it and they had to re-write it. Over complicating software costs time. Over complicating software costs money.
So how do you balance learning new frameworks while trying to keep software simple? There is a saying, KISS as long as possible. Imagine you are the one that will be coming along 10 years later to add new features to the application you are working on now. Do yourself and every other developer that comes along to maintain it a favor by writing as simply as possible. Shift your heart and your mind. The purpose of writing code well is to solve a business problem, not to puff yourself up.
You can apply the KISS principle to other areas as well.
- Keep your Software Development Life Cycle process as simple as possible. The level of Ceremony should correspond to the risk of the software. If you are building software for a Fighter ejection seat, the Ceremony will be much higher than if you are building software to manage deals at a car dealership. Most of the software that we create is not life threatening if it does not work perfectly.
- Do not create long drawn out requirements where the business rules are repeated throughout the document. Requirements are good if they can be easily understood by the business, developers, and testers; not if the printed version is hefty. Requirements are done when the developer has enough information to implement and testers have enough information to test.
- Do not test what is already being tested. Get with the developers to find out what they are testing and spend your time writing test scripts for what is not tested.
- Keep your life as simple as possible. Don’t buy things that you won’t use. In fact, if you haven’t used something in 10 years, donate it to the poor. Don’t do things that are a complete waste of time. Do things that have a positive impact that lasts.
The KISS principle goes hand in hand with Single Responsibility Principle and YAGNI which we will cover later.