Today we’re going to focus on a sentence that will make almost any developer, even a mild-mannered one, want to box up their red Swingline and head to Tahiti for early retirement.
I believe that software developers strive to do the best work they can. Most programmers will fight tooth and nail, work evenings and weekends, and scale Mt. Everest on their hands to make sure they don’t let their team down. I am, of course, speaking of teams that don’t have morale problems. While I acknowledge that they exist, they’re not the focus of this article.
In the context of a high-functioning team, some developers have the innate gift of self-motivation and strive for their best at all times. For others it’s the team dynamic that keeps their hands on the keyboard. As a developer learns to rely on his teammates and trust relationships form, they make it difficult to coast for fear of letting the group down and the thought of being dubbed the weakest link. This amalgam of competition and camaraderie is what helped companies like Google, Apple and Microsoft dominate their markets and convince their employees to work 90 hours a week and love it.
But getting back to the point: what’s the one sentence that makes software developers angry?
You might be thinking it’s the insidious:
“This bug is only reproducible on Opera v0.3 for the Commodore 64, but fix it anyway,” or the always favorite
“We don’t have a design yet, but start building something because our deadline isn’t moving”.
Nope on both counts.
This sentence I speak of is the lesser known:
“Build higher quality software in the same amount of time.”
That’s it…only ten words, fewer if you overlook some grammar rules. So why is this sentence so potent?
On its own merits, the phrase build higher quality software in the same amount of time will not incite your software developers to riot. But let’s examine the underlying message.
The Triangle
Quality and speed are two of the three forces in the famous three-sided triangle of quality, speed and cost. It’s a fairly well-known business principle that you can choose two of the three sides of this triangle; anyone who tells you otherwise is trying to sell you something. As an aside, if you buy what they’re selling, send me an email ‘cuz I have some Beanie Babies I’m looking to get rid of.
There are many definitions of “quality,” but in this article I’m speaking of software that is well-designed and well-written so as to ensure high availability (high uptime) and make it easy to maintain and extend.
With that in mind, let’s look at what happens if you keep cost the same, meaning you don’t hire more developers, but want to develop higher quality software.
You could ask your developers to work more hours. This would likely work temporarily, at least, since more time usually translates into increased productivity. It’s debatable whether someone performing work as concentration-intensive as programming is able to function well after a solid 8+ hours, but I’ll give you the benefit of the doubt on this one. Even so, studies have shown that “continuing scheduled overtime has a strong negative effect on productivity.” So for the short term we can bring out the whip and expect a slight jump in productivity, but assuming we want something that lasts longer than a few months and don’t want to experience a McDonalds-esque churn rate (because that would inevitably increase our cost and decrease the quality of our software), let’s throw this option out the window.
Another option would be to hire better people. This has a decent probability of increasing quality over time, but it’s not a solution one can implement overnight. With a team of 20 developers you’re probably looking at nine to twelve months to clean out less-productive developers and fill it with solid talent, assuming you have a few less-productive members on your team. However, if your development team is already a group of “coding machines,” or if your goal is to implement something immediately then another avenue must be explored, even if you decide to pursue this one for the long-term. Training and/or mentoring is a variation of this option with similar advantages, but a similar time-horizon.
Another alternative would be to simply make your people work harder.
Hmmm…this is an interesting one. If you buy what I said at the start of this article, that most developers are already working at or close to their best due to personal or social reasons, then this hypothesis doesn’t quite pan out. How can someone who’s already working at a high level of productivity all of a sudden work harder? Making someone work harder simply by asking them to is…well…hard to understand.
And that’s why telling someone to build higher quality software in the same amount of time is insulting, because you’re essentially telling them they’re not giving it their best effort. That they’re screwing off.
And that makes people mad.
How do I know this? Because someone said it to me the other day. Not just me, in fact, our entire development team.
Better Software
A non-technical manager told us that we have to build better software in the same amount of time, and even included the phrase “No excuses.”
Needless to say morale has seen a slight decline in the days following as developers express their feelings of defensiveness. People who’ve been giving it their best suddenly feel taken for granted and frustrated, especially the ones who’ve been working extra hours, solving project issues in their spare time, and running performance tests on the weekend. When you’re already working hard it’s difficult to hear someone tell you to work harder.
The talk was prompted by a recent issue where some high-availability systems were down for the better part of a day. These systems were written over the past 4+ years under perilous death-march schedules, with little QA because we were in a hurry to get them out the door. When they went down people panicked, and rightfully so, since many of our customers were foaming at the mouth.
As a result management expressed their concern with the situation, indicating that something had to be done as we move forward. As I was listening I understood “Make better software; reduce risk of failure.” As most developers would agree, this is a great approach, and one that several members of our team have been advocating for for quite some time. I became excited at the thought of ensuring we have ample QA and including more safeguards in our code. But my parade soon ended in a blizzard when I heard “I don’t want to hear excuses about how things are going to take longer. We can get things done fast AND better.” And that’s when I realized I needed to write this article.
But wait, there’s a little more.
A comparison was made between our software and the software of a large financial organization (think Wells Fargo or Washington Mutual). If you’re thinking “I can’t remember the last time one of those guys was down for an extended period of time,” you’re right; they typically aren’t down, and when they are it’s not for very long. But an interesting thing I’ve learned in the past few years is that the software development cycle for these guys is loooooong, to the tune of 2-3 times what our timelines run.
In other words, they’ve decided to take the “time” side of their pyramid and make it really big in exchange for a really big “quality” side. And good for them, because they’ve obviously made a wise choice, as indicated by their availability.
Now that we’re faced with the same dilemma it’s time to pay the piper and admit we need to lower our risk while at the same time admitting to ourselves the sacrifice that it will ultimately require: time.
The Moral
There are at least two morals to this story
The first is that you will eventually reap what you sow, so don’t compromise your design. Fight tooth and nail and push out timelines if you have to. This is not going to be easy, so good luck. Let me know if you discover any secrets because I would love to hear them.
The other is that reducing risk takes time. At this point I should add that it’s our responsibility as technical folk to educate those who don’t know this. A concept that appears so clear to us may not be apparent to a person outside if the IT department. We’re the only people that truly understand the complexity of the systems we build and the ramifications of spending too little time on design or QA.
Reducing risk is a lot like having insurance – if you elect to have it you have to pay for it.
Send this article to a manager or co-worker who’s tried to convince you otherwise.
