The very first version of Microsoft Word for Windows was considered a "death
march" project. It took forever. It kept slipping. The whole team was working
ridiculous hours, the project was delayed again, and again, and again, and the
stress was incredible. When the dang thing finally shipped, years late,
Microsoft sent the whole team off to Cancun for a vacation, then sat down for
some serious soul-searching.
What they realized was that the project managers had been so insistent on
keeping to the "schedule" that programmers simply rushed through the coding
process, writing extremely bad code, because the bug fixing phase was not a
part of the formal schedule. There was no attempt to keep the bug-count down.
Quite the opposite. The story goes that one programmer, who had to write the
code to calculate the height of a line of text, simply wrote "return 12;" and
waited for the bug report to come in about how his function is not always
correct. The schedule was merely a checklist of features waiting to be turned
into bugs. In the post-mortem, this was referred to as "infinite defects
To correct the problem, Microsoft universally adopted something called a "zero
defects methodology". Many of the programmers in the company giggled, since it
sounded like management thought they could reduce the bug count by executive
fiat. Actually, "zero defects" meant that at any given time, the highest
priority is to eliminate bugs before writing any new code.
Joel Spolsky, "The Joel Test: 12 Steps for Better Code"