If You Need to Brag About How Complex It Is, You’ve Probably Built It Wrong

“One of the biggest enemies of any software system is complexity.”

I have recently found myself repeating this sentence over and over again in most of my discussions. It does not matter if I am talking to my engineering team or the product team or the stakeholders or even casually with some friends over coffee. Somehow in most of my discussions, this comes up.

In one of such discussions, someone was explaining me about a really cool project with multiple technologies involved and a lot of moving parts. He ended with the phrase – “This is definitely one of the most complex projects”. For me, as much as it sounds cool, it is a red flag.

When I think about this in hindsight, a lot of people feel or at least have an impression that if a system is complex, it must be good and/or advanced.

BUT it is actually the complete opposite of this.

As the complexity increases, the quality goes down. The effort needed to maintain, debug and enhance the system shoots up dramatically. And if there is a need to onboard new engineers on the system, it just becomes a nightmare. I have seen good engineers failing just because the system is too complex and they are not able to meet the expectations of the company in defined timelines.

People often underplay or don’t even realize the importance of constantly evaluating the system for added complexities. It is always a good idea to take a step back from new feature development at times and look back at the system to find unnecessary complexities and eliminate them. If this is not done regularly, then we end up adopting the necessary evil – REWRITE the whole system.I call it an evil because it takes a toll on the business. There is a huge development cost that goes into it and usually no new features are built while the whole exercise happens.

Takeways:

1. Use design patterns to keep hard to understand pieces abstracted while maintaining the overall simplicity.
2. Do not introduce multiple moving pieces to the system like unnecessary micro-services and/or libraries. Just because you can do it, doesn’t mean you should.
3. Keep evaluating your system periodically for complexity. If there is something that cannot be explained in one go, it most probably needs to be revisited.
4. Use tools to aid in all of this. Monitoring tools are an engineer’s swiss knife.

TL;DR – Don’t write software systems which are complex to build. If you need complexity while building something, then in most cases you are building it wrong.