Deliberate simplicity
Managing complexity in systems development
Simplicity can often feel like an ideal that is just out of reach. Imagine stepping onto a busy office floor on your first day at a new job in a large company. Your ears pick up many different conversations, and everyone appears to be moving with purpose. In the beginning, everything runs smoothly, but as time progresses, projects pile up, and dependencies grow complex. The once-clear lines of communication blur, leading to disagreements rather than collaborative decisions. Soon, the organization becomes a maze where responsibilities are unclear, and meaningful progress feels far away. Everyone wants to improve the situation, but no one knows how. Complexity has crept up on everyone and there seems to be no way back. If only we could go back to simpler times! If you have worked in an organization of any scale, this may hit close to home.
Evolving systems tend to grow more complex as time goes on. No matter if it’s a mobile app, an organization, or an application platform - more features are expected of systems over time, calling for more code, more roles, more committees or more systems. Additionally, because these systems are digital or social rather than physical, it is difficult to inspect them. I am repeatedly finding that simplicity must be preserved through cycles of evolution.
The need for simplicity
Complex systems require more cognitive load for both developers and participants or users of that system. A risk is that this leads to more and more meta discussions about the systems, rather than what the systems are trying to achieve. Newcomers need more time to get acquainted and experienced participants have more trouble getting their point across. A higher lead time for changes in the system often occurs. Thus, there is a cost to complexity, which weighs heavily in development decisions.
Without careful consideration, simplicity erodes quickly as changes are made to the system. While speed may be preferred in the short term, systems with a long life cycle must remain robust. When quick changes are followed up with more quick changes that are not carefully considered and tested, this can lead to cracks in the system’s foundation. Subsequent additions may cause the whole structure to collapse. You’re then left to clean up the mess.
…But not too much
Of course, not all complexity is avoidable. In fact, some topics are just very complex. The simplicity to strive for is therefore relative. “Everything should be made as simple as possible, but not simpler” (Albert Einstein) summarizes a healthy attitude in the continuous battle with simplicity. No matter the system context, I strive to simplify as much as possible, while taking into account that the systems need to keep performing their responsibilities.
“Everything should be made as simple as possible, but not simpler” - Albert Einstein
Strategies to keep it simple
A mix of strategies can be employed at different times to help maintain simplicity.
Before adding features and increasing complexity, state the purpose and expected yield of the change. In many contexts, 80% of the consequences come from 20% of the causes (Pareto Principle1). Are we adding a (potentially) major improvement to your organization, or just more structures that have to be maintained, understood, and considered for relatively little gain?
When changes are designed, the fundamental requirements on which the system was built, may change as well. This may lead to the entire solution becoming suboptimal. A new purpose may prefer a new structure. Should other aspects of your system be altered as well to re-optimize the system for its new, expanded purpose? If you decide to stick with your original change, some time to rework the rest of the system around it may be useful.
After changing a system, periodic evaluations of the change can gauge whether it has the desired effect. Inspecting and adapting the change based on real-world experience usually beats all of our theorizing and hard thinking. Going back to the previously defined goal and yield is a good way to see if the change is living up to the plan, and can guide decisions on how to proceed. Should we do more of this, or is the change less useful than anticipated?
Periodically, I consider whether systems I work with need pruning - for example by reducing responsibilities or roles. An intricate understanding is needed about the role of all parts before making such decisions. What are the responsibilities of the part under inspection? How will these responsibilities be carried out when this is gone? When talking about his strategy for building rockets at SpaceX, Elon Musk said, “If you are not occasionally adding things back in, you are not deleting enough.”2 If that is the case for building rockets (actually rocket science), I consider it for my own business contexts (usually not rocket science). By specifying beforehand what your criteria are to call the change a success, you can reduce the risk of falling into the sunk cost fallacy3.
We need all the support we can get in discussions around simplicity. An understandable representation is the foundation on which shared understanding can be reliably built. Creating and maintaining a clear description of your system - as lightweight as possible - pays dividends. Once the contents of the system are visible or readable, all stakeholders can verify that they are on the same page with everyone else. Discussing about vague, intangible structures is a recipe for misunderstanding and leaves me with uncertainty about the chosen course. A clear representation of the system under discussion contributes to clarity - which certainly is a component of simplicity.
In conclusion, there is a cost to maintaining simplicity, but if we do not pay it, the interest of complexity will become unaffordable quickly, and adaptability of our systems plummet. I evaluate loss of simplicity at different stages when building systems, and occasionally try to reduce complexity. This leads to healthier and more adaptable systems. Clear system representations improve the understanding of those involved.
I’m curious to hear your take on simplicity! Please share any thoughts you have on the matter.
Additionally, if you’d like to read my future work, considering subscribing to be notified when I post new findings.