23rd of February, 2010
Good developers always strive to become better. We spend time searching for the perfect language, the perfect framework, the perfect IDE, the perfect testing tool, the perfect methodology.
Building great software requires all of these things, albeit nothing is perfect. There is no perfect methodology, language, or tool. At times we focus so much on the most complex things that we forget how to do the most simple things, like designing software that people actually enjoy using. In some large organizations it can feel like a single line of code is a million miles away from the person using the application. In some large organizations it can feel like everyone is more interested in delivering projects than applications, meeting targets rather than delivering an amazing user experience.
Good developers always try to deliver amazing software in spite of these obstacles. The perfect methodology for our team may not integrate well with the rest of the organization. The perfect programming language may be unknown to most developers on the team. The perfect architecture may require three months to develop but the deadline is three weeks away. Eventually we discover a harmonious balance between pragmatism and idealism, or we struggle to produce quality software. How does a team who is forced to compromise eventually triumph and deliver software that is reliable, easy to maintain, and a pleasure to use?
I recently watched the movie Che by Steven Soderbergh. I’m trying to avoid writing a lame analogy that compares software development to war, I’ve heard them before. I worked with a guy that served in the military briefly, or at least dreamt that he did. He endlessly compared software development to building an aircraft, taking off in an aircraft, piloting an aircraft, dropping bombs from an aircraft, eating a snack in an aircraft, and landing an aircraft. I never did quite figure out what he was talking about, but I assure you I’m not going to compare software to a plane. Or a bomb. Or snacks.
That being said, a specific quote from the movie Che caught my attention:
In War and Peace, Tolstoy remarks that military science assumes that the bigger the army, the stronger it is. On the other hand, only vaguely do they recognize that during military combat the final strength of an army is also its true physical capacity multiplied by one unknown x. This x is none other than the spirit of the troops measured as the greater or lesser desire to fight and confront danger. Men with the desire to fight, who also understand why they are fighting, regardless of who they are fighting, whether under the command of military geniuses or those of normal intelligence, fighting with clubs or with machine guns that fire thirty rounds a minute, these men will put themselves under the most advantageous conditions for fighting and they will triumph.
The effect morale has on team performance is staggering.
I once worked on a project that was practically doomed to failure from the beginning. The design had been bounced around and re-assigned from developer to developer like a hot potato. It was underfunded, underestimated, and practically written off by upper management. All of a sudden the client had to have it delivered yesterday. By the time our team took over, it resembled a stray cat that had been sleeping in an alley for five years. The team was feeling low, real low, but we had one previously unknown x on our side. Our manager.
For the next eight weeks, our manager refused to go home if a member of the development team was still at work. He brought us dinner, checked to see if we needed coffee, offered unrelenting encouragement, and stood up for us when upper management wondered why it hadn’t been completed ten days before we even started.
A number of small gestures added up to become something much larger. He understood the constraints we were under, but more importantly, we knew that he understood. He didn’t just understand from an ivory tower perspective, he understood from a human perspective. He understood the toll the project took on our time with our families, on our hobbies, on our sleep. He reminded us that there was a light at the end of the tunnel. We did our absolute best under some fairly dismal circumstances, and we eventually succeeded as a team.
Obviously, it’s impossible to work under these conditions forever. But working with a great team, with a great manager, and on projects you believe in will give you the motivation to push through some fairly insane obstacles; even the corporate-imposed inertia variety.
Another quote from the movie Che:
A real revolutionary goes where he is needed. It may not be direct combat. Sometimes it’s about doing other tasks; finding food, dressing wounds, carrying comrades for miles, and then taking care of them until they can take care of themselves.
A real developer feels the same way. So does a real architect, and a real manager. Sometimes it’s not about the task of writing code, but the task of helping others. When I was first starting out in development, I came to work feeling under the weather. I didn’t want to miss a day and burden the team. It was brutal cold outside, so my manager brought me lunch without even asking if I needed anything; she remembered that I always went across the street to buy it. She refused to take my money when I offered to pay her back. She also reminded me that I was part of a team, and that coming to work sick was counterproductive. If everyone else became sick, we would be far worse off than if I had taken some time off to get better. I never forgot those small gestures. Eventually she was promoted higher up the corporate hierarchy, and trust me, I did everything in my power to help along the way.
Morale.
It’s no different than a developer staying late to help out another developer, a tester learning how to automate regression tests, or an architect digging into code if the team is behind schedule. Teams with high morale do all of this. Teams with low morale, regardless of any technological or process advantages, do none of this. Teams with low morale stick to job titles and commuter schedules. High performing teams recognize and foster a culture of support rather than rewarding the heroic efforts of any one individual superstar.
I don’t think there is a one-size fits all approach to boosting morale. There are some universal, common sense things that everyone should do, like treating people with respect, asking questions instead of pointing fingers when things go wrong, and making sure to acknowledge people when they lend you a helping hand. But everyone has a different agenda at work, so something that boosts my morale may have the opposite effect on someone else. Some folks only write code for the paycheque, while others are passionate about development and really want to make great software. As a manager, I think it’s critical to identify who is who and assign them to the right roles. Empower the people with passion and they will constantly strive to make the organization better. Assign the paycheque developers to tasks that need to get done but aren’t very challenging or interesting (assuming you can’t simply replace them, which is easier said than done).
As a developer, you can do great things if you work with a great team, a great manager, and on projects you believe in. Cut yourself loose if all three of these conditions aren’t met, otherwise you’re just wasting time.
Motivated people with high morale will always put themselves under the most advantageous conditions to succeed, regardless of the challenges they face.