SIMPLE Solutions

Introduction

In modern software principles we often hear the word simple, keep it simple stupid (KISS) for example, but what does “simple” really mean? I decided to research this topic and hosted a discussion to find out what the industry thinks the meaning of a simple solution is in todays climate. From my own experience, research, and discussions, I have come up with a working definition of simple, packaged into an acronym as we all know the software industry loves a good acronym.

SIMPLE

S – Straightforward

I – Iterative

M – Manageable

P – Single Purpose

L – Legible

E – Extensible

Straightforward

The simpler it is to explain, the simpler it is to understand. Any ambiguity in the requirements will lead to ambiguity in the implementation. Solutions are always a journey from point a to point b. Think in terms of modern software development which mostly involves receiving data, transforming it, and sending it to the next part of the system. The more difficult the journey is to explain, the harder it will be to keep track of. Defining a concise, direct, and confined solution within the correct boundaries will lead to a better implementation.

Iterative

Once you have a straightforward description of the problem and solution, seek the minimum viable product (MVP). Reducing the barrier of entry means you can deliver value faster. How often do we see great ideas with real business value get diluted by scope overload? What begins as a simple idea soon becomes an unreachable utopian mess of grand delusion. Iterative also refers to the way in which you do something. Solution design is more than just writing software. Working in a way that you can repeat consistently, builds confidence in the process and help to keep it transparent within the organisation.

Manageable

When designing a solution, the more transparent it is within your organisation, the simpler it is to maintain. A simply managed solution encompasses more than just code or infrastructure. As seen over the years, people, transparency, and technological choices are overlooked in favour of what is currently trending or easy. A great example of this is the overuse of micro-service architecture. When thinking about micro-services it’s easy to think about how smaller pieces would be less complicated to reason about, I mentioned that exact point above, or how parallelising workflows would increase performance but what about the management of those smaller services? If you have a team of only a few people, does having a large amount of services make sense? From my experience it does not. I see many teams struggle to create value because they are tied down to maintenance. I myself fell into this exact trap when I created a micro-service architecture.

Single Purpose

Solutions need to have a purpose in order solve a problem. In my experience when a new feature or system is being designed, it usually starts off as this big idea with no boundaries or clarity. What is often seen with these situations is that a great idea is presented, and after a few sessions we’ve lost the original purpose of the idea and now we have multiple different purposes. Ideas create other ideas which is healthy and expected and there is nothing wrong with new ideas being generated out of others. The problem comes in when you take on multiple ideas in the same solution space. Rather have more than one solution in this instance and keep each one confined to its original purpose. When you reach this point, the solution becomes clear and simple to manage.

Legible

Readability is subjective, especially in the software industry. Different programming, domain, and business languages add to our cognitive complexity. A simple solution should be easy to read and understand in the context of the domain. The goal of Domain Driven Development (DDD) is to create ubiquitous language around a domain, I suggest going further and extending this to solution design as well. When describing the solution high level everyone should be able to understand what it means. When choosing what programming language or technology to use for the solution, it’s easy to get pulled into using the latest trends. While new tools might provide good solutions overall, if your organisation doesn’t use that programming language or doesn’t have the means to buy-in to the new technology, this will lead to a greater level of complexity. When designing the software itself, using well known patterns will increase the readability of the code, thusly reducing the amount of cognitive load needed to reason about its functionality.

Extensible

There are many schools of thought around what state we should leave a solution in to consider it complete. Being extensible doesn’t mean it should be in the extended state, rather keep it open to be extended. If there is a clear path to extend a solution in the future, then there is an easy way to reason about evolution. Not all evolutions are obvious from the beginning so rather than extending it for the sake of extending, we should aim to never close the door on an evolutionary path. This does not mean an inventory service should be able to evolve into a login service, it simply means that inventory might change in the context of the domain over time and we don’t want to inhibit the natural evolution of that domain. Extensible over extendable because we never know how business requirements evolve over time.

Investigation

I recently hosted a session at Xebia Knowledge Exchange and asked a group of 24 people in our industry this question. I divided them into groups of 6 using the liberating structures format. From this, I found the following words were used to describe what simple meant to them in the context of solution design space.

Group 1

Effective/Efficient
Low rules/cognitive-load
Contextual

Group 2

Understandable
Intuitive
Compact

Group 3

No unused functionality
Low interaction
Cohesive

Group 4

Follows pattern
Small
Explainable

Group 5

Simple ≠ easy
Adaptable
Atomic

Group 6

Uncluttered
Structured
Straightforward

This session proved to be a really interesting discussion because the general consensus was very close to my own ideas and everyone had some definition they understood and used. The main takeaway for the group was that simple ≠ easy. Secondly, the biggest discrepancy between my own ideas and the groups was that they didn’t have any iterative idea about breaking up the problem into smaller repeatable pieces.

Conclusion

I can conclude that although we all use different words to describe “simple”, we all have a very similar idea about what it means. There is however, a lack of a strong definition. The above definition represents a line in the sand to bring focus to what we really want to consider simple, how that translates to our industry and how we all should strive to create simple solutions. The main issue with using language to describe language is we can pick each word and dive into its meaning, language is subjective. So instead of thinking too much about each word, the acronym I have provided serves as a reference point. Each word is based on experiences I have had in the solution landscape and think that many others share these experiences. I believe that using this as a foundation will yield better solutions for the future.

This idea started out as an investigation and discussion therefore I encourage anyone who reads this to leave a comment. I would love to hear what you think “simple” means?