Do you fix bugs before writing new code?
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 methodology".
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
Read all about it from the link given below...
http://www.joelonsoftware.com/articles/fog0000000043.html
Comments
Post a Comment