I have been in the software development business for well over twenty-five years and have seen many successful and unsuccessful projects. The past ten years have been on teams following Agile principles to varying degrees. The teams have always been composed of different levels of experience and expertise, and I have been very fortunate to have been on teams that were mostly experienced developers, and importantly open-minded developers.
Over this span, I have seen patterns of behaviour emerge that, on the surface, seem beneficial to the team, the product, and the company, but in reality come with a lot of unrecognized costs. These costs are not planned for, not quantified – they are unmanaged. Oftentimes they are never historically reconciled.
There is one particular behavioural offender in this developer ecosystem and it might surprise you. I’m talking about the hero developer.
Meet Hercules, a member of our mythical development team. Hercules fits fairly well into the team, communicates reasonably, and is a competent developer. He gets his work done consistently. But where he really shines is when there are looming, seemingly impossible deadlines. He is the one that stays up into the wee hours, throwing himself across the finish line just-in-time.
He is the hero. He is the one who gets the adoration of managers and that good ole back slap with an “at-a-boy”. Honestly, he really loves the attention and approval from his manager and the awe from the junior developers who hope to grow up someday to be like Hercules.
Managers see the deeds of Hercules and know that this is how successful software is created. If only they had a bunch developers just like Hercules, their software problems would be solved.
A Deeper Analysis
First, let’s acknowledge that being dedicated to your team and working hard are assets and that these assets are not found in all developers. But when we look at Herculean deeds from an Agile point-of-view, we start to see issues that can undo all of the gains that came from the providence of Hercules.
Hercules specializes in cranking out code in a short amount of time. Sometimes it seems the more pressure, the better. Hercules knows that code. Due to time pressure, he didn’t get to do a lot of the unit or integration tests, but through sheer ability to focus, he delivered today’s functionality, and that’s what’s important, right?
Hercules sure knows that code, but the other developers do not. The agile developer wants group code ownership. They want group input on design choices. They want the most well thought out, flexible code that the company and project can afford (girded by time and money). The agile development team wants to de-silo the implementation, meaning that multiple developers are familiar with the code so future changes occur at a reasonable cost. But given the supreme, single source effort, the odds go against this.
A good hero sees heroics as an aberration – something to be avoided if possible. But I have seen cases where heroes use heroics as a path to job security. They hoard information by being the only custodians of said code, such that others recognize their area expertise. They want to make sure that there is a large painful hole in the development team should they ever leave. Naturally, job security like this is good for them and really bad for the company.
Another issue involves scaling the team. If you have a Hercules, it is almost impossible to clone him/her. You should be able to find developers, but if you need one to fit into a chaotic, barely-managed environment, you need another Hercules, and they are both harder to find and cost more money.
The final drawback is a bit more subtle. Tom Demarco’s book “Slack” (https://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficiency/dp/0767907698) does a good job of discussing the issue. In a nutshell, if you have heroics as your normal means of delivering software, your heroes are 110% busy – and this means time for creativity and giving back (like mentoring) fall by the wayside. This cost is never recognized by management but can have a very large impact on the business over time.
Hire as many heroes as you can and avoid heroics at all costs.