It's harder than you might think to squander millions of dollars, but a flawed software-development process is a tool well suited to the job. This chapter from The Inmates Are Running the Asylum untangles the expensive confusion of deadline management.

This chapter is from the book

It's harder than you might think to squander millions of dollars, but a
flawed software-development process is a tool well suited to the job.
That's because software development lacks one key element: an understanding
of what it means to be "done." Lacking this vital knowledge, we
blindly bet on an arbitrary deadline. We waste millions to cross the finish line
soonest, only to discover that the finish line was a mirage. In this chapter
I'll try to untangle the expensive confusion of deadline management.

Deadline Management

There is a lot of obsessive behavior in Silicon Valley about time to market.
It is frequently asserted that shipping a product right now is far better
than shipping it later. This imperative is used as a justification for setting
impossibly ambitious ship dates and for burning out employees, but this is a
smoke screen that hides bigger, deeper fearsa red herring. Shipping a
product that angers and frustrates users in three months is not better
than shipping a product that pleases users in six months, as any businessperson
knows full well.

Managers are haunted by two closely related fears. They worry about when
their programmers will be done building, and they doubt whether the product will
be good enough to ultimately succeed in the marketplace. Both of these fears
stem from the typical manager's lack of a clear vision of what the finished
product actually will consist of, aside from mother-and-apple-pie statements
such as "runs on the target computer" and "doesn't
crash." And lacking this vision, they cannot assess a product's
progress towards completion.

The implication of these two fears is that as long as it "doesn't
crash," there isn't much difference between a program that takes three
months to code and one that takes six months to code, except for the prodigious
cost of three months of unnecessary programming. After the programmers have
begun work, money drains swiftly. Therefore, logic tells the development manager
that the most important thing to do is to get the coding started as soon as
possible and to end it as soon as possible.

The conscientious development manager quickly hires programmers and sets them
coding immediately. She boldly establishes a completion date just a few months
off, and the team careens madly toward the finish line. But without product
design, our manager's two fears remain unquelled. She has not established
whether the users will like the product, which indeed leaves its success a
mystery. Nor has she established what a "complete" product looks like,
which leaves its completion a mystery. Later in the book, I'll show how
interaction design can ease these problems. Right now, I'll show how
thoroughly the deadline subverts the development process, turning all the
manager's insecurities into self-fulfilling prophecies.