Many people thing that all software is this tangled-mess of really complex instructions that only these wizards called coders can understand. In reality, most engineers would agree that most of the code they work on is actually really simple. The worst code they have every worked one was code that was hard to read and unnecessarily complex.
In fact, I think the best code is the code that avoids complexity like the plague. Instead of complexity, it prefers simplicity.
I’m sure you have heard of KISS. No, not the band. Not the romantic gesture either. KISS stands for Keep It Simple Stupid (or Keep It Short and Simple, Keep It Simple Silly, etc). It’s a principle designed to keep engineers, teams, or anyone really from over-thinking and over-complicating a task or solution.
KISS states that simple systems should be preferred over complex ones. The rationale comes from the fact that simple things are easier to understand and easier to fix than complex ones. The idea is often attributed to Kelly Johnson (one of the leader engineers on the SR-71 above) when asking a set of engineers to design an aircraft. He asked them to design it in such a way that the aircraft could be repaired with simplistic tools at a combat airfield. A tall task to be sure. Especially when that aircraft was planned to go faster than the speed of sound…
You might be reading this and think “Sure, but my system does some pretty complex things”. If that is you, keep in mind that KISS is a design goal. Design goals are different from a business requirements. If the business requirement is to accomplish a complex task, such as doing eye-tracking for example, then you can’t control that. However, you can design the system that accomplishes the complex business requirement in such a way that it itself is simple. Meta, I know.
Some of the top benefits of having a “simplicity first” mindset when it comes to code are:
- Easier to implement
- Easier to maintain
- Allow for natural improvements over time
- Meets immediate needs faster
As a quick example, lets say you need to water your lawn (a quarter acre lawn for concreteness). You decide that instead of getting out a hose every few weeks and walking around your lawn to accomplish this, you want an automated solutions. Maybe not fully automated, but you want to water your lawn without spending hours walking up and down your lawn. You don’t want to get sun-burned after all 🙂
You could accomplish this by simply getting one of those famous sprinklers that goes back and forth across a specific area of your lawn. You would set it up in a corner, hook up your hose, and let it go. Then after a while, you move it to a different place. You haven’t spent that much time with initial setup or moving it and you could likely water the whole lawn in a day.
Another option however would be to install a full-fledged irrigation system. This system would have an automatic timer, be connected to your water supply etc. You wouldn’t ever need to even go outside to water your lawn.
How do you decide?
One way would be to figure would be to perform a simple cost-to-benefit analysis. While I won’t go into detail about estimation here (be on the lookout for a post later!), you would want to estimate your cost of implementing a solution to the benefit (performance, revenue, etc. being potential benefits). In this example, it would likely be comparing how much time you saved on watering the lawn to the cost of parts and effort in both scenarios.
One of things I think you will notice quickly is that the second option, installing an irrigation system, might be harder to estimate. I personally wouldn’t know where to start myself. So naturally, I’ll increase my estimate since I don’t understand it. The first solution, however, is easier to estimate. I also can likely do some simple thoughts on how much time I would save on lawn maintenance in both.
Here is a simple (and albeit trivial) graph with what this might look like. The units on each is sorta made up – kinda like Story Points:
When I do that analysis, its clear that I would indeed save more time with a full automatic irrigation system. Just install it, turn it on, and let it do its thing right? The problem is that the cost is daunting. Installing it takes longer; I might need to plan more before I even get to start installing; it seems like a rather large project for me and my no-so-great building skills (or even gardening skills for that matter). I realize that the simple sprinkler is easier to implement.
I also realize that the complexity of this irrigation system has a lot of connections. Connections that could break, get blocked, etc. That would be a lot of time if I had to fix it. Especially given that the project was at the edge of my comfort zone, I might have very well made a mistake earlier. I realize that a simple sprinkler would be easier to maintain.
Last, I realize that if I decide to change how my garden is laid out, that would likely require a large change to my irrigation system. It might even mean a substantial cost increase. Of course I’m not sure since I can’t predict the future. I realize that a simple sprinkler doesn’t require a huge change if my lawn layout changes – and I can always buy more or place a few in set locations if needed. I realize that a simpler sprinkler allows me options for improvement in the future.
The other benefit of the first option, because it is easier to implement and doesn’t cost as much to implement, is speed. I can go buy a sprinkler and have it ready for this weekend. I’ve accomplished my goal faster.
I know, I know. Lawn care is extremely trivial in comparison to building dynamic software systems. Software systems have larger trade-offs; costs are always harder to estimate; requirements are never as simple as “save some time watering the lawn”.
And while all of those things are true, I still believe starting simple is the best approach. It must meet the business requirements of course, but it might not be the most optimal in the long-run. That is OK. Really it is. Part of agile is discovering how requirements change as you build your solution. Maybe the simple solution doesn’t meet the needs of load as you discover how it is used and performs in production. New requirements might come up in the next three months. That is always possible – dare I say expected – with agile methods.
This is where starting simply really shines. If you have been doing regular iterative cycles on this solution, you will be well prepared to correct these problems. these new requirements are likely not out in left field. You have probably been seeing some of them coming over time. That simple solution will have already been experiencing natural changes as a result. Because it was so simple to start, you can easily allow it to grow and morph to fit your needs.
Wrapping it Up
To wrap it up:
- The KISS principle states that the simplest solution that you can get working and maintain should be preferred over others
- Simple solutions allow for more natural iterative development within an agile context
Now go forth and become a good KISSer! (too much? Ok… sorry).
Let me know your thoughts in the comments! Till next time…