This article was originally published on June 11, 2012 at Dotnet @ Kape ni LaTtEX and edited to update links accordingly
Roy Osherove asks why delivering software on-time, with quality suggests that everyone is failing at the quality front:
Many of us keep chasing quality and never achieving it, because we don't know how to make time. We don't have any time to learn/teach the team and practice true quality code (unit testing, tdd, acceptance and automation to start with) because we're in chaos and we are addicted to it.
Our lack of time makes our decision to focus on "getting things out the door" more frequent, and so we have more quality issues and even less time, because we just have more and more fires to put out.
Several times in my career I've encountered the interview question on whether I'm a tinkerer or a perfectionist. A tinkerer hacks and hacks and hacks at solutions to get them working and out the door as quickly as possible. A perfectionist will constantly improve existing code until he almost reaches the point where he can't improve it anymore.
My answer would be that I'm always leaning on the latter: I code at a much slower pace than many (a cause of frustration for some bosses) so I could keep a tight watch on doing things "the right way". I have had to temper this tendency though, because it does sacrifice the timeliness of my deliveries and gets me into trouble. Quality is fine and dandy, but if its not demonstrable, it's hard to justify.
Jeff Atwood goes as far as positing that the speed of delivery is much more important than its quality, when he delivered this presentation in this year's Atlassian summit:
Boyd's law of iteration: speed of iteration beats quality of iteration - Coding Horror
So, where will you place yourself in these conflicting beliefs about delivery and quality? I think that the real problem lies on our definition of "on-time". Our timeliness is based on schedules brought about by estimates in task length, and the fact that everyone totally sucks at estimation is the ultimate cause of our frustration.
We want to hack at either quality or delivery because these are tangibly solvable problems. Software estimation, on the other hand, is a very, very, very hard problem to solve. Understanding how hard it is is key to understanding why software developers work 60-80 hour weeks into death marches. Its difficulty is best illustrated by Michael Wolfe's answer to the Quora question: Why are software development task estimations regularly off by a factor of 2-3?:
Let's take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach. I'll whip out my map and draw our route down the coast:
The line is about 400 miles long; we can walk 4 miles per hour for 10 hours per day, so we'll be there in 10 days. We call our friends and book dinner for next Sunday night, when we will roll in triumphantly at 6 p.m. They can't wait!
Wow, there are a million little twists and turns on this coast. A 40-mile day will barely get us past Half Moon Bay. This trip is at least 500, not 400 miles. We call our friends and push back dinner til Tuesday. It is best to be realistic. They are disappointed, but they are looking forward to seeing us. And 12 days from SF to LA still is not bad.
We get up the next morning, bandage up our feet and get going. We turn a corner. Shit! What's this?
Goddamn map doesn't show this shit! We have to walk 3 miles inland, around some fenced-off, federally-protected land, get lost twice, then make it back to the coast around noon. Most of the day gone for one mile of progress. OK, we are not calling our friends to push back again. We walk until midnight to try to catch up and get back on schedule.
My friend says, well, we've gone 40 miles in 4 days, it is at least a 600 mile trip, so that's 60 days, probably 70 to be safe. I say, "no f--ing way... yes, I've never done this walk before, but I know it does not take 70 days to walk from San Francisco to Los Angeles. Our friends are going to laugh at us if we call and tell them we won't see them until Easter!
So, if it's really hard to do good estimates, is there a point in the quality vs. delivery conundrum?
I'll give a few points that worked in my experience:
- Never let anyone do estimates for you - you need to own up to this if you're going to be good at it, and only you know how long you'll probably take to do a task.
- Include quality in your estimation - if you want better quality, you'll have to factor it in. If that means factoring in unit-test writing or refactoring in your estimates then so be it. You can't produce quality software in quick-and-dirty time.
- Break down your tasks to the smallest possible units of tasks - you can't have quick iterations if the tasks aren't small.
- You can't make it perfect - accept this quickly and you will prevent yourself from having analysis paralysis.
- You'll make estimation mistakes, ergo, it won't ship on time - Ditto. Especially true as the project size grows and schedules lengthen.
I hope that helps you keep your sanity in this eternal battle.