Software engineers tend to be enamored with complexity. Yes, systems and programs are complex by nature. But the truth is a little more … sinister.
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 ways to waste time and money. Tremendous !
A complex system provides hiding spaces for incompetence, laziness, or just lack of velocity in a poorly maintained stack.
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 extract “fix it” out of “this steel alloy won’t survive design temperatures, but better alloys are a year away.”
Given incompatible management requirements — fix it now, now is impossible — we will need to take cover in the hiding spaces. Complexity.
Software vs other engineering disciplines
In other engineering disciplines like aviation or structural engineering, often lives are on the line. A poorly designed engine, automobile, airplane, building, can leak, crash, collapse, explode. Dead passengers, ruined infrastructure, hundreds of millions of dollars of damage — none of this can you “roll back” or “hotfix”.
In software, however, there seem to be few consequences 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 fundamental principles of software craftsmanship ? Is there any depth to a candidate’s knowledge ? In just 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 scope of our technical details. We don’t know how to train junior 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: Get better. Broaden your technical 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, many technical excuses will be legitimate. Ultimately it will fall to you to decide. Why not equip yourself to make better decisions.
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, appreciates how humans tend to fail, and then takes proactive action to anticipate problems, facilitate relationships, and remove roadblocks.
Maybe we could find a name for that job …. “Human Resources” maybe ?
Damn, it’s already taken. Oh well.
Happy hiding !