Software engineers tend to be enamored with complexity. It’s a self-serving instinct, and what do you know, but management falls for the lie. Every. Single. Time.

Who does complexity benefit ?

Complexity actually is quite advantageous – for the individual developer.

With a complicated codebase, the architect can impress people with their personal raw intelligence. New developers who pick up the complexity enter an “informed” group and earn esteem from their peers and management.

Or, perhaps the general consensus on your codebase is, “it’s legacy, it sucks, but we have to deal with it for now.” Well, this is even more useful. We can blame delays on the legacy codebase, and, we can build a replacement system, make that complicated as well, and now we have two projects ! Tremendous !

A complex system provides hiding spaces for incompetence and laziness.

Now, software in general is difficult enough, that even a system designed for simplicity, will still fail for complexity.

Unfortunately, at the management level, it all sounds the same. Management tends to lose patience with technical details. They don’t care what the technical details are … steel or aluminum, gold or platinum, it all sounds like “problems with the metal” and management’s direction will be “just fix it now.” Whereas the software developers – the metallurgists of the bits – are the ones who actually have to pull “fix it” from “this steel alloy won’t survive design temperatures, but better alloys aren’t available yet.”

Given incompatible management requirements – fix it now, now is impossible – we will need to take cover in the hiding spaces. Complexity.

Software vs other disciplines

In other engineering disciplines like aviation or structural engineering, often lives are on the line. A poorly designed engine, automobile, airplane, building can fail, crash, collapse, explode. Dead passengers, hundreds of millions of dollars of damage – none of which you can “roll back” or “hotfix in production”.

But there are few consequences in software for poor individual performance. Jobs are plentiful; simply having enough years on the right tech stack is usually enough to secure the next gig. Do you write good code ? Do you understand good coding principles ? Is there any depth to a candidate’s knowledge ? With a few hours of interviews, this can be quite difficult to determine.

Additionally, software developers are paid too much money relative to other engineers. In a world where the gold makes the rules, if you’ve got a ton of gold then clearly you’re doing something right. Why get better ? Why improve ? Why accept any critique at all ?

The solution lies in better management

Most tech companies face hiring problems, and are obsessed with finding “senior” developers.

This is another way of saying, “As management, we don’t understand and can’t manage the depth of our technical details. We don’t know how to train young engineers. We need senior developers to pick up the slack of what we’re unable to manage ourselves.”

Here’s a game-changing concept for management: broaden your horizons. Study Agile processes and learn how to implement them effectively, not as dogma, but as efficient process. Learn and study technical details – not to become experts, but to be able to make better informed decisions. You want to not be hoodwinked by lazy developers; but at the same time, some or many technical excuses will be legitimate.

In an underachieving enterprise of collaborating humans, somebody has to pick up the slack. Some group has to be the dynamic force which understands human interactions and appreciates how humans tend to fail.

Somehow I thought that was what “management” was supposed to mean.

But hey, what the f**k do I know.