06 November 2012
TweetI’m a sucker for epic movies. I especially enjoy the epics where regular people are put in extraordinary circumstances. Heroes with no super powers, or unlimited resources, are forced to face off against seemingly insurmountable odds. And after a long struggle, the heroes emerge victorious. These stories inspire me and drive me to be more like the heroes. But how can someone who writes code for a living aspire be a hero or even resemble the people in these movies? Most people see coding as a docile and individual activity occurring in a tranquil setting. There’s nothing epic about typing words on a keyboard…or is there?
Many enterprise software projects run much like the epic war movie We Were Soldiers. A company tasks a few battle hardened veterans to lead a whole bunch of young, inexperienced, and often delusional privates into a dangerous high risk situation. There’s incomplete information, constant churn, and careers hanging in the balance. Enterprise software development is jungle warfare. And jungle warfare requires heroes.
So what does a hero look like on a software development project? The Hollywood depiction of a rock star developer is the guy pulling all-nighters to write thousands of lines of cryptic code that leaves mere mortals awe struck and dumbfounded. Other developers are afraid to even touch the code assuming they are even smart enough to comprehend it. Sound about right? Well I’m going to challenge that perspective. Developers like the one described above do exist in our world, but are they heroes? Well… yes, but they’re more like the guy who sacrifices himself to cover a grenade early in the movie. In general you want to avoid creating situations where this type of hero emerges. Gen. George Patton said it best when he said: “The object of war is not to die for your country but to make the other guy die for his.” The type of hero described above often allows the development project to hit the date, but creates an unmaintainable mess for everyone else. The survivors of the grenade attack are happy to be alive, but they’re fighting a man down for the rest of the movie. Shit happens and if a grenade rolls by it’s important to have people in the group that are willing to jump on it. But I wouldn’t want to create a culture out of it, because after a while you’ll run out of people.
So let’s talk about the heroes that I’d like to see more of: the hero that confronts danger head on, inspires greatness all around them, and does what’s right instead of what’s easy. I call them Hands-on heroes.
Most of my favorite epic movie characters can be classified as Hands-on heroes: William Wallace (Braveheart), Maximus (Gladiator), and Hal Moore (We Were Soldiers). None of these men are above the fray. They stand side by side with their men and face-to-face with whatever adversity is in front of them. To bring this back to the world of software development, these are the men Fred Brooks refers to as “Thinker Doers”, the rarest breed in the software world. These are results driven leaders that have abandoned the pursuit of the ivory tower. Instead they embed within the team actually doing the work and contribute directly to the end result. For these folks failure is not an option.
The thought of putting leaders in the trenches flies in the face of most organizational structures. The best are supposed to rise to the ivory towers and scale their efforts out. They’re too valuable to put in harm’s way. However, the ivory tower removes leaders from the situation on the ground which distorts their reality. There is a difference between moving figurines around a map and giving orders while bullets are whizzing by your head. Just like there is a difference between moving people around on a spreadsheet verses dealing with individuals face to face when allocating work. The argument could be made the other way that the ivory tower allows people to think more strategically by removing the person from the situation. It’s true that it can be harder to make rational decisions on the ground especially you’re close enough to the people for them to pull on your emotional strings. But is the purely rational decision always the best one?
Jonathan Haidt makes some very interesting points related to decision making in his book The Righteous Mind. Haidt cites extensive research demonstrating that strategic reasoning follows intuition. So the person in the ivory tower is still going to first follow their intuition, but without having a relationship with the people impacted by the decision there’s not going to be much weight given to the decision’s effect on the people involved. Therefore the decision appears to be reached more rationally. The problem with this mindset is that not weighing the emotional response to decision making (even in a purely technical one) carries some consequences. Why can’t we just consider the emotional response as another piece of data? It’s easy to try to distill technical problem solving down to a problem of reason. However, as Gerald Weinberg states in The Secrets of Consulting “it’s always a people problem”. So decision making without proper consideration of the “people problem” is likely not going to lead to an optimal decision. These problems are best understood by the Hands-on heroes since they’re on the ground floor. It’s on the Hands-on hero not to give too much weight to the personal reactions. The overall success of the project is still the top factor.
Another staple of epic movies is not only the hero stepping up their level, but inspiring people around them to go above and beyond what they believe possible. Organizations that are under constant pressure to create innovative technical products or services require technical expertise. And unless they’re willing to pay a lot of money to consultants and expert hires they need to figure out how to grow new technical people internally. Hands-on heroes don’t buy the people around them, they grow them. In Gladiator, Maximus is surrounded by a group of fellow slaves that function as a small army by the conclusion of the movie. Some people are self-driven and will grow themselves without direction. Others need a little push. Both types can benefit from the leadership of Hands-on heroes.
For many new developers, understanding where to start can be challenging. Pair-programming is a hands-on technique that can be used to allow a team member to absorb knowledge by watching how a more experienced person solves a problem. This also allows the hands-on leader to observe the other person’s work strategies to suggest improvement areas. On the other side self-motivated technical people can get stuck in the mentality that they have to learn everything that’s out there. This can lead to the creation of a technophile. Wikipedia defines this type of person slightly different than I do (http://en.wikipedia.org/wiki/Technophilia ). I define a technophile as someone who learns a bunch of technologies for the sake of knowing them, but never really connects the dots to build platforms. A hands-on leader can differentiate a platform built on buzz words from a platform built on complementary frameworks. Complementary frameworks allow developers to focus on the domain problem instead of technical problems; buzz word platforms allow people’s resumes to grow. Hands-on heroes inspire people to grow skills that complement each other. Skills must be learned to serve a purpose and those skills must be constantly improved. Teddy Roosevelt was another Hands-on hero, he articulated this idea quite well when he said, “Power undirected by high purpose spells calamity; and high purpose by itself is utterly useless if the power to put it into effect is lacking.”
Finally hands-on heroes believe in karma. They don’t do the easy thing; they do the right thing. Doing the right thing is often a learned behavior; many times it’s because they’ve seen where the easy path has led. It would have been easier for William Wallace to admit treason to the English and receive a quick death, but the legacy of his quest for independence would have been tainted. For developers, it’s easy to deliver a project without unit tests if you know you get to walk away at the end. It’s easy to write methods with cyclomatic complexity over 20. It’s easy to Ctrl-c and Ctrl-v. But if you stick around your community long enough, it’s a matter of when (not if) it comes back to bite you. Code has karma, bad code perpetuates itself. But so does good code. Anyone that’s walked on to a project that has 80% code coverage knows the guilt you feel when you add a class without writing tests for it. Hands-on heroes know that the things they produce are meant to live on well past their time on the project. They understand that doing the right thing perpetuates others doing the right thing. They give others something to aspire to and leave a legacy worth remembering.
Delivering great software can be epic. As in all epics, heroes must emerge for the good guys to win. The current trend in business today is to remove the heroes from the fray and put them in ivory towers. The intent is to better scale out the hero’s talents, but often this only causes their efforts to be diluted. Battles can be won or lost in the trenches. It’s important to ensure that the right people are in these positions. Great software requires Hands-on heroes.