Blog Superman is a villain in the software development world
Superman is cool. Growing up, everyone wants to be like him. He can fly. He is super strong. He can fix anything, even the threat of nuclear war! In Hollywood, Superman is cool.
Unfortunately, in the software development world, Superman is not so cool. Being a “hero” in the our world usually means that something went wrong and someone stepped up to fix it. My issue isn’t with the person who steps up and fixes the problem. We all end up being the hero from time to time. My issue is with cultures that reward heroic behavior at the peril of behaviors that would prevent issues in the first place.
Take for example unit testing. I have worked in a number of software shops that either frown on or just don’t do automated unit testing. I’ve heard all the standard reasons not to: It takes too much time, why write more code to test your code, etc. In their eyes, unit testing is clicking around with a browser (in the case with a web application). When things end up breaking in production or in any other inopportune time, the hero comes to the rescue, fixes the issue and is praised for saving the day. In this example the issue is a symptom, not the true problem and unfortunately by rewarding the hero the underlying problem goes unfixed. The cycle continues.
A better solution would be to incorporate a retrospective. In the retrospective, the team can discuss what happened, why it happened and how to prevent it in the future. Action items can be assigned to address the true issue (automated unit testing in this case) and the hero is not needed as much.
I once worked for a manager who told me that he wanted to work on a team where “everyone was willing to be a hero”. My response was “I want to work on a team that doesn’t need heroes”. The goal shouldn’t be to be a hero. That only works in Hollywood. The goal should be to prevent their need in the first place. What are your thoughts on heroes? Let’s hear it in the comments!
The fact of the matter is that there are ALWAYS going to be things that go wrong. By solving the problems, you can be a hero.
By the way, you spelled “villain” wrong.
Hero or not, but I think decent level of expertise should be expected and I hope nobody would like to go under a knife under a supervision of a mediocre surgeon or have business evaluated by nasty CPA. Software world is not exception either.
I think in the examples cited above the problem is not whether there is a hero or not. And in general, people who deliver working software are generally rewarded. The question here is what risks are we will to take when planning project releases. Serious testing reduces the risk, but generally does tend to push back delivery dates.
To put the blame on a hero developer is just wrong. A good software process will never replace a group of good people. With exceptional people you can do just about anything with or without good process.
I don’t think we should promote mediocrity, just to make sure the team members all follow the rules.
Amen.
Reminds me of the line from Bertolt Brecht: “Happy is the land with no need of heroes”. The hero developer is, at best, a tool. He allows shoddy management to continue operations for one more cycle. He prevents necessary change from occurring. At worst, he’s a cynical agent of dysfunction, actively contributing to conditions that demand heroism.
I think the logic is a little backward.
Why punish the hero for doing the right thing? Instead of calling the hero “the villain”, let’s call the real villains “the villains”. The real villains create the need for the hero.
We should all strive to be heros. What is a hero anyway? Someone who hones their skills, is agile, intelligent, and constantly strives to be better. We should all try to become that.
The problems you mention come from the need for heroic action because of poor practices. Let’s fix those. Let’s not bash the folks who are trying to improve.