What is Simple?

Seems like an easy question. And yet, the point of view, the context on which the question arises, will show you that the answer is usually not that easy.

Structural Complexity

A single method/function that contains all the code is, structurally, simple. But when you need to read the code that structural simplicity works against you as you need to read more of the code to understand all that is happening. Same when you need to modify the code. The bigger the code it is, the worst the damage from that structural “simplicity”. Which is way subprocedures were added as a way to simplify the reading and editing programs.

But you can add too much structure, and the simplicity that you achieve for reading/editing can disappear. When you need to add a change, if there are too many elements that need to be changed in ways that make them more brittle or that take you too long because of the interdependencies, you haven’t made the code simpler, you have augmented the structural complexity, without the benefits to the basic reading and editing activities.

Deployment Complexity

To get a system deployed on cloud, you can simply create a VM, using the console/portal/whatever-name, upload the artifact/executable, and get it to run. It only takes a few minutes nowadays. And if you need to update, you drop a new artifact/executable. That makes for a very simple deployment process. But, redoing the environment, is a bit more complicated, because you need to remember all the specific configurations that you set up. What about having different test environments? How easy will it be to mess up having completely different setups on each environment? Do you need to run tests? Where are you running those tests? What happens if the tests fail? What happens if they succeed?

But once you start setting up your system to make it simpler to deal with those questions, maybe you are adding complexity that negates any benefit. You are using an infra-as-code approach, and a deployment pipeline. How easy becomes to add a new environment? How many places you need to touch? What are the dependencies between the different steps if you need to create the whole setup again? Have you even tried?

Process Complexity

You can have a team/organization completely devoid of process. Get some work to do, get on your computer and do it. Nothing simpler than that, correct? But what happens when your CTO/CEO changes their whim every other day? How you make sure that you are not doing the same work as someone else? How do you know if you are building the right thing (or even the thing right). What looks like a simple process becomes complicated as soon as you look at it from different point of view. So you want to add a process, so it becomes simpler to deal with those scenarios.

But the process can grow into something too complicated, hindering the delivery of the system, forcing you to talk non-stop with other teams/parts of the organization. It can introduce too many gateways. Trying to improve the flow, has the effect of constraining the flow.

Simple is not Easy

That title is a quote from Kent Beck, that I heard some years back. If you want to make something simple, first you need to know what kind of simplicity are you looking for. Then, getting to that simplicity will take time; will probably take you through paths that don’t make it simple, so you need to backtrack; you will be scratching your head about how to make the system/process simpler. To make things simple requires experience, understanding of the systems and processes that you are using or could use, knowledge of the pros and cons of each one, the point of views and contexts on which they actually do not provide simplicity, but complexity.