اولین نسخه Word تحت ویندوز، پروژه « نوحه مرگ » محسوب می‌شد که نوشتن آن به درازا کشید، فرجه‌ها دایماً به سر می‌رسیدند؛ افراد تیم، ساعتهای مسخره آمیزی کار می‌کردند، و پروژه باز … و باز … و باز به تاخیر می‌افتاد. استرس باور نکردنی بود. وقتی بعد از چندین سال، بالاخره محصول لعنتی‌اش بیرون آمد، مایکروسافت کل تیم Word را برای استراحت به جنوب مکزیک فرستاد ؛ و خودش به کنکاش روحانی جدی دست زد.
مایکروسافت متوجه شد که مدیران پروژه آنقدر بر حفظ « زمان بندی » (schedule) اصرار داشتند که برنامه‌نویسان مجبور به کد نویسی با عجله شده بودند، و بسیار بد کد می نوشتند – به این علت که فاز bug fix جز زمان‌بندی رسمی نبود. تلاشی برای پایین نگهداشتن تعداد خطاها وجود نداشت. حتی برعکس، روایت شده که یکی از برنامه‌نویسان که مسؤول نوشتن کد محاسبه ارتفاع خطوط متن بود، فقط نوشت: return 12; و بعد هم منتظر نشست تا در گزارش باگها بیاید که تابع‌اش ، همیشه درست کار نمی‌کند. زمان‌بندی پروژه صرفاً تبدیل شده بود به لیستی از باگهایی که باید تولید می‌شد! بعدها، از این اتفاق با عنوان « متدولوژی عیوب نامحدود » (infinite defects methodology) یاد شد.
برای حل این معضل، مایکروسافت « متودولوژی کمترین عیوب» (zero defects methodology) را به صورت فراگیری اتخاذ کرد. بسیاری از برنامه‌نویسان داخل شرکت خندیدند – چون به نظر می‌رسید مدیریت به این نتیجه رسیده بود که با یک حکم سازمانی تعداد باگها را کم کند. اما در واقع، معنی « کمترین عیوب» در این است که در هر لحظه، بالاترین اولویت در رفع باگهاست، نه نوشتن کد جدید. اما چرا؟
به صورت کلی، هر چه برای تصحیح یک اشکال بیشتر معطل کنید، هزینه تصحیح آن (از لحاظ وقت و پول) بیشتر خواهد بود.
به عنوان مثال، وقتی که اشتباه تایپی انجام می‌دهید و کامپایلر آن را catch می‌کند، تصحیح آن کار اساساً ساده‌ایست. به همین ترتیب، بار اولی که کدتان را اجرا می‌کنید و در آن اشکالی می‌بینید، می‌توانید بلافاصله آن را تصحیح کنید، چون همه کد در ذهنتان وجود دارد.
اما اگر در کدی که چند روز پیشتر آن را نوشته‌اید، ایرادی بیابید، یافتن محل دقیق آن مدتی طول خواهد کشید، البته وقتی که کدتان را باز خوانی کنید همه چیز بالاخره یادتان می‌آید و در یک زمان قابل قبول مشکل رفع می‌شود.
اما بالاخره اگر در کدی که چند ماه پیش آن را نوشته‌اید باگی پیدا شود، به احتمال زیاد چیزهای زیادی را در مورد آن کد به فراموشی سپرده‌اید و تصحیح آن بسیار سخت‌تر است. ممکن است مشغول تصحیح باگ کد کسی شده باشید که در آن لحظه برای مرخصی به جزایر دریای کارایب رفته باشد. در این صورت، تصحیح باگ به صورت یک علم در می‌آید : باید با درایت، وسواس، نظم و بدون هیچ تصوری از مدت زمانی که یافتن راه حل طول می‌کشد، عمل کنید.
اگر در کدی که تحویل داده‌اید ایرادی بیابید، متحمل هزینه باز هم زیادتر برای اصلاح آن خواهید شد.
پس اولین دلیلی که باید باگها را بلافاصله رفع کرد، کم کردن زمان لازم برای این کار است. دلیل دیگری هم وجود دارد: پیش‌بینی مدت زمان لازم برای نوشتن کد جدید، راحتتر از پیش‌بینی زمان لازم برای رفع یک باگ است. مثلاً اگر از شما بپرسم که چقدر زمان برای نوشتن کدی برای مرتب‌سازی یک فهرست لازم دارید، جواب نسبتاً دقیق می‌توانید به من بدهید. اما اگر از شما بپرسم در جایی که IE 5.5 نصب شده باشد و کدتان دیگر کار نمی‌کند چقدر زمان لازم دارید تا باگ مربوطه را رفع کنید، بعید می‌دانم که حتی بتوانید حدسی بزنید! چرا که (بنابر تعریف صورت مسأله) نمی‌دانید که منشأ مشکل کجاست. ممکن است سه روز وقتتان را بگیرد، ممکن هم هست که فقط دو دقیقه.
به بیان دیگر، اگر در برنامه زمان‌بندیتان تعداد زیادی باگی که باید رفع شوند، وجود داشته باشد، زمان‌بندیتان غیر قابل اعتماد است. اما اگر تمامی ایرادهای شناخته شده را تصحیح کرده‌اید و فقط کد جدید مانده، زمان‌بندیتان به طرز حیرت آوری دقیقتر خواهد بود.
نکته خوب دیگری هم که صفر نگهداشتن تعداد باگها در هر زمان دارد، عکس‌العمل سریعتر در برابر رقباست. بعضی برنامه‌نویسان این قضیه را به « آماده تحویل بودن» محصول در تمام لحظات، تعبیر می‌کنند. اگر رقیب شما امکان مشتری‌کُشی عرضه کرد، شما هم می‌توانید آن امکان را فوراً به برنامه‌تان اضافه کنید و آن را تحویل دهید، بدون این که مجبور به تصحیح تعداد زیادی ایراد انباشته شده باشید.
