Keep It Simple, Stupid

Keeping it simple is one of the basic requirements for sustainable software delivery. Many of the problems we encounter trace back to unnecessary complexity. By avoiding that complexity, we can increase our likelihood of success, decrease cost, and stay sane.

When I started working as a developer ten years ago, this was one of the first pieces of feedback someone gave me. A more senior dev was looking at some complicated code I was writing and told me, "keep it simple stupid". Over the years, I've come to realize how important this is as a principle, even though I still struggle to remember and apply it. And it turns out that most people have the same problem.

Human beings are really bad at keeping things simple. We have a tendency to underestimate the growth rate of complexity. When you add something new to a system, it could potentially affect everything that's already in the system. So in the worst case, if you have N moving parts, each new part increases the potential complexity of the system by N. That quickly gets out of hand. In reality, everything doesn't touch everything else, so the growth rate is usually less. But we just love to add more moving parts, and we're not very good at keeping them decoupled. So the complexity grows beyond our ability to manage it.

More complexity causes more uncertainty. When things become sufficiently complex, we don't know what all the parts are and how they're interconnected. The system becomes a giant pachinko machine into which we drop little balls which bounce around and who knows where they'll end up. Of course, there is logic to it, and we can trace the path of the balls. But the more complex grows, the harder it is to predict what is going to happen, and the harder it is to keep adding new parts to the growing system.

Over time, the people working on the system become increasingly confused about how it works. But there is urgent pressure to deliver value, so we do our best. And we continue to change and add more moving parts. But because of the increasing complexity and uncertainty, delivery processes start to degrade. The same tasks become slower, more painstaking, and more error prone. At this point, we should pause and take the time to reflect and figure out how to stop digging ourselves deeper. But that would put our deadline at risk, so we decide to prioritize short-term delivery wins over long-term sustainability of the system. And the complexity and uncertainty keep growing.

More complexity causes more fragmentation. The more the complexity increases, the more people will become specialized in different areas. This specialization leads to individuals being siloed from each other, with differing knowledge, context, and priorities. People take ownership of separate areas, and either avoid or are shut out of other areas. This makes it harder for everyone to see eye to eye, to have shared understanding and make consensual decisions.

Complexity, uncertainty, and fragmentation all feed each other. Confusion increases, progress slows down, and the group can't seem to agree about anything. But we push ahead, maintaining the status quo. Because people are more uncertain, they lack vision of the whole system and make less informed decisions. Because people are fragmented, they start optimizing locally for their individual contexts instead of integrating their work cohesively into the whole. And so more ad hoc changes are made to the system, further increasing complexity.

Now we are trapped in a vicious cycle and things spin out of control. People respond to the dysfunction by becoming afraid, frustrated, and telling themselves fictions. The interpersonal dysfunctions of the team become intertwined with the dysfunction of the system they are working on, creating even more problems.

Is there another way? Can the system develop differently to prevent this tire fire?

One key part of the answer is to "keep it simple, stupid!". People will say that's obvious or reductive. And it's inflammatory to call people stupid. All of that is true. But in spite of the fact that the principle is obvious, most of the time we fail to follow it. Over and over again, we build complex systems that overwhelm our collective capacity to manage them. And we must be seriously misguided if we keep making the same mistakes. So we need to continuously remember not to overcomplicate things.

The challenge is in keeping it simple while still capturing the essential complexity of the core problems at hand. And doing this while under constant pressure to deliver more value. And also dealing with growing uncertainty and fragmentation at the same time. We'll get into those topics in future posts.

If you made it through to this point, please do me a favor and give feedback in the comments section. What did you like about this blog post? What could be improved? Also, what are your thoughts on managing complexity?