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.
