Why keeping it simple is good for software delivery

KISS – the keep-it-stupidly-simple principle – is one of the first principles introduced to software developers. It is a mantra that provides a host of benefits to technical and business professionals at all levels. 

n this post, I illustrate how this principle can be applied outside of code, across all aspects of your technology organisation, and how this mindset leads to faster, safer, and more valuable software delivery on time and on budget. Let's look first at the value of simplicity in a range of example contexts:

• Simple iterations lead to faster feedback.

• Continuous integration of small changes is easier than periodic integration of large changes.

• Successful usability testing is not effective without a simple, well-defined scope.

• Simple PoCs and MVPs get your product to market minimal waste.

• A simple roadmap is easier to follow.

• A simple plan doesn’t get distorted as it gets communicated to others.

You can easily see that keeping things simple is a valuable business strategy. The irony is that adhering to this principle is not always easy. Simple and easy are not the same thing so understanding the value of simplicity helps you apply KISS even in the toughest situations.

What to do when keeping things simple isn’t easy

How do you take the beautiful designs that will spearhead a new branding initiative and structure them in a way that allows their day-by-day release via a series of safe, simple and stable changes?

Collaboration across disciplines. Ensure early input from specialists from across the whole team. Share a single vision and cultivate a common understanding of the reasons why things are being done, leaving the what and the how to the specialists who will carry out the work.

How do you take a meticulously constructed architectural design that will lead you from your old unwieldy software into the shiny new world of CI/CD, and arrange it into something simple that adds value to your organisation week by week?

If necessary use a detailed plan to pick a point on the horizon to aim for. Hold onto the vision but focus on the simple steps that are immediately in front of the teams. Remember, simple plans are easier to change so remain vigilant against overcomplicating. Obstacles that are far off in the distance will be easier to address when you get closer to them, so be cautious about over preparing for every eventuality.

Remember...

In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.

Antoine de Saint Exupéry

What to do when you don’t know how to keep it simple

If you can’t find a simple next step, that is an indicator of a problem. In code, we would call such an indicator a “bad smell” because it draws attention to something that is not right. Just like in life, the really good work cannot start until the bad smell is cleaned-up.

“Drawing back” or “moving up a level” is a concept that can help here. The classic way to explain this is using the example of a map. If you are zoomed in to the detail of a street view you will find it massively complex to navigate from your house to a hotel in another country. You have to draw back to a higher level, where you can see the two countries at the same time and plan a route between them. You might then zoom in to a level of a city where you can see the relationship between the hotel and your place of arrival in that city. Once you have a simple view at that level you can move down into the exact lefts and rights you need to make to get all the way to the door of the hotel.

So what do you do when you cannot find the simple next step? Immediately draw back from what you are focused on and try to describe it from one level higher up. The sooner you do this the sooner you will be able to return to the details you were previously focused on. Sometimes you’ll find you no longer need to at all.

One method for drawing back from a confusing situation is to list the challenges as either, simple, complicated or complex.

Simple, complicated, and complex challenges

• Simple challenges are ones without any unknowns.

• Complicated challenges include things that are unknown that you can take note of and address. These are also called known unknowns.

• Complex challenges contain the unknown unknowns, the pitfalls you didn’t even know existed.

Sometimes just recognising that a complex challenge exists allows you to take a simple next step, which is to tackle the unknown unknowns before anything else. This is a simple meta-plan that ensures that the overall solution becomes simpler as you progress.

Pursue simplicity

Simplicity should be a goal for your teams which will save them from going too deep into the details of a problem. If an organisation is looking to improve their software delivery capabilities, start from the outside of the problem and work inwards. At each level, you can achieve a full understanding of a simple map and then choose to “zoom in” to the next level with a clear picture of the surrounding context.

Simple design is achieved by maintaining well separated levels of magnitude. High-level vision can never be simple if it tries to include low-level details.

Summing up

• KISS, like DRY and the Single Responsibility Principle, is not only for developing code. It works for developing teams and developing software organisations. In this post, I’ve talked about some of the imaginative ways you can apply this principle. In any given week you can experience countless others. It is a convenient mantra to keep with you.

• Don’t get drawn into complex details until you have a clear picture of the surrounding context. Pull back from any complex problem and find a way, to sum up, what is happening in a way that makes it seem simple. Once you have that high-level view, if necessary you can zoom back in and try to simplify the details of the next level down.

• If you can’t deliver small iterations you need software modernisation. Assuming you are in a position to focus on software delivery then focus on getting each iteration to market and being able to measure its impact.

• Be ready to change directions by focusing on small, simple steps, not on complicated drawn out plans.

• Cultivate collaborative ways of working across the whole delivery team. With the right specialists in the room, the chances of someone being able to see things clearly and make them seem simple to everyone else are much higher.

When things are overly complex on any level don’t get drawn into the details underneath. You might need to move one level up to find a simple map of what is going on. Once you have this context the lower levels will be easier to simplify.

Keeping things simple is not easy but if everyone understands the value of doing it it’s an excellent guiding light for the organisation as a whole.