Info

Blog series:

  1. My simplicity toolkit: Intro (this page)
  2. My simplicity toolkit: Programming (part 1)
  3. My simplicity toolkit: Programming (part 2)
  4. My simplicity toolkit: Testing
  5. My simplicity toolkit: Architecture
  6. My simplicity toolkit: Patterns

“Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away”

Antoine de Saint-Exupery

When it comes to software engineers, I have increasingly come to value simplicity and going back to basics. I have been coding for ~25+ years (~15 years professionally) and have truly gone through The Evolution of a Software Engineer. Throughout my career I have grown increasingly worried about the growing cargo culted complexity in our industry.

In Rich Hickey’s classical talk “Simple Made Easy” he talks about the difference between “Simple” and “Easy”. Simple pertains to the lack of complexity or intricacy, while easy relates to the level of effort or skill required to accomplish a task. Hickey argues that we, as software engineers, should choose simple over easy, but often end up doing the opposite.

Simplicity is controversial Link to heading

As Hickey points out,

Simplicity is a choice.

and these days I would even say it is controversial. This includes things like focusing on simple programming language constructs, doing simple dependency injection without any dependency injection framework/library, focusing on simple libraries over frameworks, avoiding complex/complicated build tooling, smaller scoped tests, smaller interfaces, not needing microservices by default, not needing SPAs by default, avoiding as many moving parts as possible etc. Also, a focus on backward compatibility and a preference towards not using the latest and coolest tech.

Further, I am a big believer in simple solutions programming-wise; Boring code is good code. This is mainly why I have had a growing fondness for the Go programming language for the past few years.

My Simplicity Toolkit Link to heading

There are many nuggets in Hickey’s talk, but one of my favorites is the slide where he talks about his “simplicity toolkit”:

Hickey’s “Simplicity toolkit” shows complex tools in the left column their equivalent simple to the right. For example, Methods are more complex than Functions.

The thing I liked about the slide was how it made everything so much more concrete. Which solution to prefer over another. If I would ask anyone “Would you prefer simplicity?” I am sure most people would say “yes”. But by showing that simplicity is a choice, a stand against something, you force people to make a decision away from complecting things.

Above said, choosing X over Y is about preference, not a rule. I am sure there are cases where a larger interfaces are needed, where Kubernetes is a good platform to use instead of a managed service, etc. IMO, it just should not be our go-to solutions. I think the software we are building should have the same level of complexity as the business problems we are solving. By focusing on simplicity first, we work with simple constructs allowing us to gradually introduce complexity into our software.

In the next few blog posts, I would like to share some of my simplicity toolkit. Many of these preferences are the result of banging my head against the keyboard for days and nights and eventually realizing I did not need all this complexity.

You will find some of these preferences written down in my Quora post which I used to curate for many years. Others are more recent insights. I hope you will enjoy my posts - and if I manage to challenge you to simplify the software you are building, even better!

This was the intro to my blog post series about my simplicity toolkit. You can find my first toolkit post here.