Do Not Want It Good Want It Tuesday

There is an old story in the film composing business that goes likes this:

A producer and a composer are talking about the score the composer is writing. The producer is getting anxious because he needs to get the movie finished up, as it got behind schedule during shooting. The composer says, "If I gave you the score now, it wouldn't be any good." The producer then says, "I don't want it good. I want it Tuesday."

Now it seems to me that this story is just as applicable to software practices at many, many shops. Time constraints due to overly optimistic schedule estimates later end up forcing sacrifices in quality. If this industry is ever to grow up, this type of practice has to change.

-- JohnPerkins

Implicit in delivering it good would be knowing what good is, and hence when to stop. The thing about Tuesday is that everyone involved knows, understands, and agrees what it is... (until the resident CowboyCoding practioner works way past midnight, thinking that still counts as "Tuesday", but the PHB thinks 5pm COB is end of Tuesday) -- EricScheid

Excellent point. In software it is really easy to know when something is good: the specified functionality is implemented as the customer described and it passes 100 percent of both the unit tests and the acceptance tests. -- JohnPerkins

Nope. That gets you "yes, that's exactly what I asked for, but not what I wanted". It does get you paid though, if you're a consultancy, so from that organisation's perspective, that's good.

Right -- they want it Tuesday, until they get it Tuesday. Then they complain that it doesn't work quite right -- which is clearly your fault, in their eyes: "Why couldn't you build it right???" So you get beaten up and punished for not doing it right. (IE: You get punished for delivering what they asked for.) Then you may fall right into a ViciousCircle: Your punishment is to have less time and resources for the next one, so it has less quality, so your punishment...

The page title sounds like advice to ignore quality out of adherence to schedule, but the content argues the opposite. Maybe that earns it the AntiPattern badge.

If this industry is ever to grow up, this type of practice has to change.

There's some interesting tension here. In the story, the "practice" in question is being practiced by the customer. No mention is made of the composer's response. If the customer is king, and it's "their money", then what does it mean for the "industry to grow up"? Does that push the maturity ball into the customer's court?

I think the answer to the last question is a qualified yes. As engineering firms, we need to make sure the customers are educated about the choices (or demands) customers are making and the consequences thereof. Regarding the composer's response, there is none in the story. There is a story about Stravinsky being asked to do a film score. (This is just the gist.) A famous studio head invited Stravinsky to do a film score. When Stravinsky arrived at his office the studio head said, "So, you are the greatest composer alive? It is a pleasure to meet you. Tell me how long will you need to do the score for this movie." Stravinsky thought for a moment and said it could be ready in one year. He didn't get the job. -- JohnPerkins

I've often wondered why it seems that project observers ask about budget and schedule the most often and quality the least often. Actually, schedule more often than budget, for that matter. I had thought it had something to do with the schedule feeding of our generation, but now I'm not so sure. Eric's point about the relative complexity of the quality dimension makes a lot more sense. By design, we engineers are supposed to be doing the hard work, but it seems now that we need to get customers to think hard too (in the quality dimension), or else we can't serve them very well.

Is it our job to help them think hard?

-- WaldenMathews

Yup, it is our job to help them think hard. Our job is to provide our customers with the software they want, knowing that the customer doesn't know what software they want when they first ask. Part of releasing after short iterations is to give the customer smaller, rough versions of what they're asking for to get their input, to get them to think hard about what they want. --RobMandeville

I've often wondered why it seems that project observers ask about budget and schedule the most often and quality the least often. Because schedule is easy to measure ("is it Tuesday yet?"); budget moderately easy to measure ("3 programmers, 10 PCs at $1500 each..."); quality is hard to measure ("we have 143 bugs but only 3 of them are priority 1, so overall... how are we doing?"). Unless you have more rigorous ways to measure quality, like unit tests.

Yeah, except you're just touching the tip of the iceberg when it comes to measuring or even defining quality. I say this to emphasize your point. -- Walden

I suspect that there is no objective metric, nor any group of objective metrics that cannot be fooled into giving false sense of quality. I think this comes down to the fact that the quality of a thing (software or otherwise) is a subjective.... uh... well... quality. WhatIsQuality? -- MarkAddleman

I will make a claim that the reason that few customers do not want to discuss quality is because they do not want to open that door - they are afraid that once quality is admitted as a metric, they will not get the best software, and we programmers will find ways to give them bad products. What they seem to not understand that by making quality an absolute, they disallow any chance of a negotiated compromise that will meet the budget and schedule numbers they also want. See IncompatibleGoals. -- PeteHardie

There is NO way to get rid of this AntiPattern in the modern climate of contractual programming. Software companies compete on timeframe to completion or price. But price is always a factor of time. I've never seen a contract signed which expresses any terms of quality, only implementation/support/etc. Thus delivery of software according to the specification irrespective of quality is the modern mantra. One day in the glorious future maybe someone will make them sign a contract to penalize software suppliers if the quality goes below a certain rating by an independent professional quality standards group. Or penalization based on bugs found etc. Yeah, right. Since the person making these contracts are salespeople and managers who are clueless, this won't happen.

The reason salesmen and managers make a great deal more money than you do is that they are anything but clueless. They just understand different, more important, things than you do. What the guy is asking is, "can you solve the problem by Tuesday?" If you have half the grasp of your craft that most programmers erroneously claim, your bankable response is, "This is what I can give you by Tuesday..." If you've bothered to find out what the business objective is (another rarity), "this" will be the most vital part of the requirement and will keep the ball rolling until the next release. --mt

Because they believe, on the strength of long experience, that the only way to work with programmers is to inflate the need, in the hope of getting something barely usable. The way to change their minds is to commit to something you can actually deliver and then deliver it--on time, on budget, on-spec and usable. Keep doing that and you'll change the relationship to the kind I had when salesmen would call me from a client's office to ask what it would take to deliver some bright shiny object--and then sell it. --mt

Consider an Iterative Approach

"Quality" is not an absolute; quality can be improved forever. What is needed is a determination of what is satisfactory given the current constraints.

In the story at the top of the page, why hasn't the producer heard the score yet? The producer is ultimately responsible for the film, so shouldn't he have the right to evaluate the current quality of the score? Perhaps it is acceptable now or perhaps it needs work extending to Thursday or Friday. Who knows? The composer is keeping the score a secret.

Software development is similar. The stakeholders need to have the opportunity to frequently review the software as it is being developed. This allows them to make objective decisions on what is good enough. This does not mean that the software will not undergo further refinement, merely that the stakeholders can start getting some value out of the effort before the effort is completed. The software development industry needs to get away from relying on individual standards from developers, testers, or anyone else in the guise of "quality." The quality of a product is a complex concept that varies over time and needs to be openly evaluated.

Iterative development opens up the development effort for the world to see, but it leads to a fairer evaluation of quality.

CategoryStory

EditText of this page (last edited August 10, 2011) or FindPage with title or text search