Simplicity and Complexity in Software


We Know Simplicity is Good

Software developers so highly value simple and clean code that we have a multitude of well-loved and oft-repeated acronyms extolling its virtue: KISS, YAGNI, DRY etc.

I am sure you have heard of at least one.

Complexity is Still Prevalent

Despite this, software still has a strong pull toward complexity. Code is often complex, bloated, and messy. Why? If we know we should be keeping the code simple, why are we so consistently making it complex?

In my earlier years as a software developer, I used to think that we just hadn’t advocated enough for simplicity. But then every software professional I’ve met agrees when I say simplicity is best. After decades of meeting peers who are all simplicity advocates, it is hard for me to believe the underlying concept is not universally accepted, even beloved.

I also thought that maybe we were not being given enough time for simplicity. Either to pursue it to begin with, or to refactor and simplify existing code. Again, I’ve seen too many companies and projects where we were given plenty of time and budget for refactoring and cleaning up tech debt. We still ended with complex code, so it likely is not a lack of resources or time.

Humans are the Complexity

What I have come to believe is that software professionals are humans, and humans are complex. As much as we may idealize simplicity in the things we create, we are not simple. We are a messy pile of spaghetti experiences and our frequently spaghetti-like code creations reflect ourselves and our complicated nature.

Software of the people, by the people, for the people

So, what am I saying?

Software development is a human endeavour, for the benefit of humans, that is most frequently built by teams of humans, who are managed by humans.

Trust, relationship building, good communication skills, emotional intelligence and a healthy understanding and respect for human psychology are essential to doing the job well. Why do I think this? Because, when I’ve been on teams that do these things well, the code we produce is better and simpler than the teams that don’t.