Timeline and Risk: How to Piss Off Your Software Developers

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.
Irrelevant Image: Yosemite Mountains
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.
Irrelevant Image: Xela Sky
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.

Irrelevant Image: Yosemite Rapids

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.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Digg this ]

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.

18 comments ↓

#1 http:// on 02.19.06 at 6:19 pm

The XP people will say that one other parameter you can tune is scope. If your boss wants better quality in the same time, then you may need to reduce feature set.

#2 Adnan Masood on 02.19.06 at 7:57 pm

I can’t agree more. The Mythical man month discusses several disasters caused by similar kind of Dilbert’s pointy-hair-manager approach. I’d also grade it lower than add-more-people-to-get-it-done-on-time approach since it is innately accusatory to a developer saying “Build higher quality software in the same amount of time.” This approach essentially causes constant churn and brain drain in the org; people who have worked hard to build the foundation will stay for their emotional attachment but new hires will be constantly, just up and leave. Why? I’d say because if you want excellent code coverage, documentation, immaculate process flow implementation, extensibility, auditing and cutting edge architecture with security and scalability built-in, give people some time. Excuse me for the classic building analogy again but Rome wasn’t built in a day. And as Paul Graham said about architectural design “Architects know that some kinds of design problems are more personal than others. One of the cleanest, most abstract design problems is designing bridges. There your job is largely a matter of spanning a given distance with the least material. The other end of the spectrum is designing chairs. Chair designers have to spend their time thinking about human butts.”

#3 http:// on 02.19.06 at 11:27 pm

This is absolutely brilliant, because the insult is coming from folks that are taught only to trim fat, cut corners, and omit excuses; they normally don’t see the big picture that is the hard work or the long schedule. In your position, I’d gladly agree to turn out better work faster… under the condition of an immediate raise. Preferably twice what you’re making, because the way production is slowing from the upset grumbles, that’s probably what it will take to get everyone working again.

#4 http:// on 02.20.06 at 1:25 am

Lookit, you’re insulted. That’s great… it means you have a high opinion of your existing work ethic, and of your team. So, faced with this sort of challenge, you have two options. You can be the manager’s bitch, and be blamed for the inevitable. Even if you ask for a raise, you already see it coming — this project is likely in a death spiral. Or you can quit. You can see if you’re right about your skills, and those of your team. Go work for a company that values quality — you’ve identified a few in this article. Or start your own. It’s risky, leaving the familiar. It may not work out. But that’s your option. You’re not going to educate this manager, or any other non-technical manager. Their job isn’t to build software. It’s to motivate people to work until their hearts pop, then fire them and replace them with recent college graduates. The sooner you grasp this, the happier you will be.

#5 http:// on 02.20.06 at 3:01 am

The flip side: I work at a large insurance company where an hour of downtime = $millions lost for the company. We generally have 100% availability. We do review code very carefully before it gets to production, and we spend lots of time & effort on QA. But on the other hand: # Any downtime problems are usually solved as fast as possible, which usually means duct tape. # We’re *too* conservative, and pass over improvements that we have no experience with. # Because of the high visibility, QA can get paranoid, and will often opt to “just test everything manually.” We waste a good amount of money this way.

#6 RedRobot5050 on 02.20.06 at 2:47 pm

Rob, It sounds like you’re entering a death spirial. I know because I’ve been there, and the prolonged overtime doesn’t just drain your productivity and work ethic, it steals the energy from your health and social life. Its not a good situation to be in, and it occurs in this industry all too much. To be blunt, your non-technical manager is an asshat. I remember reading somewhere on an agile/xp blog that in situations like this, the way around the problem is to form a group and collectively bargain. It does not mean ‘permanently unionize and go on strike.’ Just appoint a team leader or technical lead to speak to manager on behalf of the entire team. When 20 people are not happy and demanding a 2x increase in salary, management will take notice. Especially when you go to the non-technical manager’s boss. I would also say “just plain get out”. If your manager says things like that, he doesn’t know anything about project management. Does he have any credentials? A SEI PMP certificaion? No? Get out. Companies that hire stock managers to run software projects find themselves blaming programmers for lack of ability when its really management is all to blame. I wrote a “When to get out” article on my blog. http://www.christopherwilson.net/soapbox Its about 3 posts down.

#7 http:// on 02.20.06 at 4:34 pm

It’s a bit hard to tell what your exact situation is, so I’ll leave aside the question of whether you personally are being Dilberted. However I think it *is* sometimes reasonable to aim for “better quality in the same amount of time” – as long as the timescale is long enough (an entire project or milestone). There are numerous software practices (unit testing, for example) which can be used to improve quality *and* reduce overall time-to-release. It takes a bit longer to write the code because you have test code to write as well, but you spend less time debugging weird issues in integration. I’ve seen it happen. See McConnell’s “Code Complete” for a laundry list of other practices which can both improve quality and reduce overall time.

#8 http:// on 02.20.06 at 4:46 pm

If it makes you feel better (it won’t), this happens in other industries as well. In a previous life I was a commercial photographer for a small ad/pre-press agency that aspired to play in the big leagues. I was sent off to study with some of the best photographers in North America and learn how they do it. As will not surprise you, the very best had two things going for them: They knew gobs about what to do, and they took gobs of time to do it, so they can control every detail. Sound familiar? Then a local builder comes along and wants shots of their houses that look like the stuff in Architectural Digest. I quote the job based on how the AD guys do things: one or two shots per day. My boss turns purple, his veins stick out, little flecks of foam appear around his mouth, and he informs me that we are going to do AD-quality photography at a rate of six to eight shots per day, and no excuses. Sound familiar? So less than a year later the agency is basically closing the studio (they still do yarn catalogs and such), and I’m out looking for another job. Sound familiar?

#9 rwalling on 02.20.06 at 5:57 pm

Thanks for all your comments. The bottom line, and something I should have mentioned in the article, is that I have no intention of leaving this company. Our software team is just too good and the company itself is respectful to its employees and treats us fairly. There will always be issues between management and technical people; if technical people got everything they want the company would likely go bankrupt because nothing would ever release. If management got everything they want the software would crash every third day and all the developers would leave from overwork. Somewhere in there is a middle-ground, and it’s my goal to find it. Unless the company were to become a hostile environment, which it’s not, I view leaving as giving up. If we all leave when this type of thing happens how will it ever change?

#10 http:// on 02.21.06 at 1:05 am

It will change because your current employer will die a slow death while those who value their technical talent and hire good management staff will thrive. This is evolution. Things take time. Be patient for the trends to work out on a global level, but in the mean time don’t keep working for idiots. You only have a few years to do good stuff. Make them count.

#11 Shanti Braford on 02.21.06 at 9:57 am

This comment is not about you or your team Rob… …but the sad fact is that at many big to medium sized companies, people simply aren’t *really* working as hard as they possibly can. Sometimes, it’s not their fault. These are the biggest possible reasons, imho: – lack of autonomy (some middle manager chooses the tools / technologies / etc everyone is to use by executive fiat) – bureaucracy / etc. – just like Peter talks about in Office Space, what do most people get if they bust their ass 80 hours a week? hardly anything. maybe an extra $5k per year raise, or .0001% stock in a stodgy company. – team personality issues (prima donnas, etc) – being forced to commute in to a stodgy, life-sucking cubicle work environment (when you could be 2x as productive at home or in a cafe) – Sorry if I’m being idealistic at the moment, but I’m about to start an incredible opportunity, including: – working from home – my own hours – my own schedule – working with the technologies I love (Ruby on Rails, etc) – very early employee in a thriving startup – plenty of stock (duh) – having a “manager” (though it feels just more like collaboration) who just “gets it” — we’re always on the same page w/o clashes – a technical manager, who also has great people skills (they said it couldn’t be!) It might not last forever but this is a dream opportunity and I implore anyone who reads this to stick to their guns and keep searching, if you are in a toxic work environment currently. You just never know. Tip: do what you love, even if it’s after hours, on your own terms. Eventually, *just maybe* you’ll one day have an opportunity to do it full-time. Shanti http://sablog.com/ See also: http://sablog.com/archives/2006/02/17/top-coders-20x-as-productive

#12 http:// on 02.21.06 at 3:13 pm

I couldn’t agree more, and it’s not just programmers. If you tell anyone they’re not doing their best then either they’ll buck up their ideas, if they’re being lame, or, more likely, they’ll take offence, as they are doing their best. I don’t think it’s just programmers who try their hardest day in, day out. My g/f works for a drug + alcohol project. Her + coworkers do an emotionally demanding job, that they are all outrageously commited to. However, all it takes is for the (ridiculous excuse for) management to tell them they’re not doing the best they can, and they’re all looking for new jobs. When will managers learn, this isn’t the right way to do stuff. Stumbling in with a solution to a problem you know little, if anything, about is both arogant and insulting. Imagine if I came round to your house and told you that you didn’t love your kids enough. (ok, if you had kids). Would you be pissed off?

#13 http:// on 02.21.06 at 3:15 pm

I think you’re two best options are to 1) find another job or 2) stop caring.

#14 http:// on 02.21.06 at 8:58 pm

The phrase is “reap what you sow”, unless you are mixing metaphors.

#15 http:// on 02.22.06 at 9:14 am

The assumption that programmers work at the top of their ability is completely wrong. We developers as a group seem to have a bit too high regard of their own professionalism. If you look at other industries there have been huge improvements in time, cost and quality over the years due to improved methods. This is true even for software development. Do some analysis of your own and your teams methods and I positive that you will find several areas of improvement.

#16 http:// on 04.04.06 at 10:49 pm

I wish if I can have my Planning group to read this article.. I work in large insurrance company which works with concept PBR (Plan- Build- Run) .. famous acronym from the company’s list.. do they know that every step is different than each other and can take specific amt of time.. In our case, PLANNING takes higher priority and time than BUILD… actually the equation is ( TimeLine – PLAN Time = BUILD Time )… consider remaining time for BUILD.. I totally agree with the two options that Rob gave us here… That could save our time of maintaining the low-quality software.. we can use the same time for building the next good quality software. Rob.. it was always worth to read your article and learn something new.

#17 http:// on 04.06.06 at 1:44 am

Great post. I’ve been in a similar environment where our dev team’s best efforts (above and beyond the call of duty) were met with further demands for productivity. It doesn’t get better from the situation you’ve described, though when you’re emotionally involved it is easy to believe that it must improve, that your efforts will be recognised. When we pointed out that we’d been working 80 hours weeks we were told we should be able to work a 40 hour week and meet the deadline and that any overtime we worked was down to our incompetence. After 12 weeks of ~80 hour weeks I found myself in hospital with a heart condition, at 24 I had a pacemaker. It’s just not worth it. I found the managers I worked with there to be motivated solely in getting a sale (selling unrealistic deadlines and expectations) and then pressuring, bullying and cajolling the dev teams to meeting their deadlines. If deadlines get met then the managers take the credit, when they don’t the blame is heaped solely on the development team. These environments won’t change as long as good developers stay in them, and they stay in these environments for the reasons you said you are going to stay with your employer. I’ve moved on but I’m friends with developers that still work there and their expectations that things will change, that eventually they will be recognised and appreciated is still as strong as it was the day I left and still as unrealised.

#18 Rob on 04.06.06 at 4:01 am

Great point, Ben. Your experience should serve as a warning to all of us.