Took the fam to see Kung Fu Panda 2 today. Traditional film can only support about 30 min of 3D, so seeing a whole movie in digital 3D for the first time was pretty cool. I loved it. Also, children have no inhibitions about talking through movies in the theatre. Fun times.
Every hero has an origin story. My favorite superhero is Batman. He overcame loss and through sheer determination – and a family fortune to buy some cool toys – turned it around to watch out for others, guarding them against the vicissitudes of the world, specifically the criminal underworld. Of course, I see Po’s origin story as an echo of Batman’s, but I’ll refrain from ruining it for my son.
Recently, some tester friends were discussing the nature of heroism on Twitter, including how it pertains to testing software. I’ve heard the word hero used with two completely different connotations in this context:
- Heroism as the self-sacrifice of the tester, throwing one’s self on the grenade for the good of the unit.
- Heroism as the self-actualization of the tester, realizing one’s full professional potential, which benefits the team.
No doubt we are all familiar with work situations that embody the first definition of heroism. Inevitably, the needs of customers dictate swift resolutions to problems that require an extra effort from staff members, including software testers. We manage the current crisis, wipe our brows, and return to our regular work schedule. We don’t want to cultivate situations that necessitate this kind of deliverance: constantly fighting fires is a sign that we aren’t preventing the fires in the first place.
While admirable, accepting – or even taking initiative to seek – tough assignments may not accomplish our goals in a sustainable way. The champion who constantly faces down dangers may not be taking care to restore strength between bouts and can become burnt out. Although Sisyphus could be viewed as an absurdist hero, this is not heroism I choose to imitate. In addition, an environment with one superstar can actually prevent others on the team from cultivating their own courageous abilities. We need to take turns wrestling with the big problems so that we all become more capable, which might mean a less glamorous sacrifice such as familiar regression testing – though we could even take this opportunity to improve this routine material with the knowledge gained since our last encounter.
Then again, when we have individuals with heroic talent, do we want to spend it on tasks that do not require such skills? We must avoid the Harrison Bergeron solution of bringing heavyweights back to the average level. Would the group be better served accomplishing the routine tasks in a more efficient way, such as automation, and devoting able testers to the remaining unaddressed challenges? We want our testing staff to take initiative to seek knowledge in resolving tough problems so that when software crises occur our testers are prepared to face the present trials. Constantly improving our testing skills offers clear benefits to our team in an hour of decision. Our goal should be “building a fighting force of extraordinary magnitude,” where our metric is one of ability, that develops each person’s heroism.
Preventing the formation of heroes would not tamp out circumstances that call for heroics. Why do we create or foster circumstances that routinely demand a hero to set things right? Let’s not be Lois Lane, living for the moment of rescue to admire the Superman who has saved us. We need to stop tying the lady to the tracks, to stop distressing the damsel, and to free up our heroes for the real fight, facing external threats rather than internal ones. While the value of heroism is under discussion, the real topic of conversation should be why heroism is necessary.