I make life easier, that is to say I've been writing software for 9+ years. Eschew hype; focus on delivery and performance.

Living in Switzerland đŸ‡¨đŸ‡­ since 2017.

Essential and Accidental complexity, and performance

In case you've never heard of these terms, they can be defined simply as follows, starting by the basic words:

Simple means that it is plain, plainly visible, easy to understand, individual and probably not composed of many parts.

Complex means to make an interconnected whole, usually composed of simple(r) parts.

Essential complexity is part and parcel of the problem. It's intrinsic. You cannot get rid of it. It just comes with the problem. Only way to get rid of it is to change the problem. For example if you're launching a rocket, essential complexity would include the fact that you have to break off from the pull of gravity.

Accidental complexity is what you add on top. In other words it's what the development team (particularly the programmer) adds in complexity. Normally comes in some form of "code has to ..." rules, but could simply be poor design.

The concept evolved first from the paper No Silver Bullet—Essence and Accident in Software Engineering by Fred Brooks.

It was later expanded on by the paper Out of the Tar Pit by Ben Moseley and Peter Marks.

While I don't agree with the papers' conclusions entirely, these terms are an extremely useful model to think about complexity.

Why would you add accidental complexity? For one of three reasons:

  1. Skill issues
  2. Faithfully following practices that add complexity (Clean Code(tm), SOLID, OOP, GoF, etc.)
  3. Management forced you to

The first two, funnily enough, can be improved by simply looking at skillful programmers program under high performance constraints.

Their solutions may be unusual for most of us, but due to the high performance constraints they are forced to keep things simple, otherwise it will not perform well enough.

So this is my thought of the day: perhaps to keep things high performance we just need to keep them simple, and stop adding abstraction on top of abstraction just to stay in line with some "it's how we should do things" pattern of thought.

The software industry rarely produces high quality software, maybe it's time we took a second look at what we consider "standard practice".

Further reading