Self-Inflicted Accidental Complexity

A lot of the time it’s something we are doing that’s making it painful.

The above quote is from a friend whose a software engineer at a young startup. Their team is fighting for product market fit and fighting self-inflicted accidental complexity. Fred Brooks did not foresee in 1986 that buying could become the source of accidental complexity.

here are some of the things that happened:

The decision was made to build the app with a new web framework. It means they would be one of the first people to find out how it breaks. They couldn’t just StackOverflow(or ChatGPT) the issues they come across. The framework comes with an ORM that doesn’t support all the features of their database. It means changing the approach to fit the ORM or crossing abstraction barrier and writing some raw SQL.

The main app is in JavaScript and they have other services in Python. It means two deployment pipelines that need to be maintained. Switching programming languages is not just about different syntax, there are different idioms, there are different tools, there are different ways for them to break.

They’ve already changed some core third party libraries a couple of times. This was to correct previous decisions, but that was a lot of time spent not dealing with the essential complexity of their market.

avoiding accidental complexity now means buying well

You have to evaluate the abilities of your team, the quality of open source libraries, the quality of SaaS vendors, and what should be built rather than bought. There’s a new skill for engineering leaders, how to minimize the accidental complexity so that your engineers can spend the maximum time on the essential complexity.