تست پنجم جوئل: آیا قبل از نوشتن کد جدید به رفع اشکالات کنونی می‌پردازید؟
باگ بخش جدایی ناپذیر تولید نرم‌افزار است. تست پنجم جوئل رویکردی ساده را ارائه می‌کند: قبل از اینکه به سراغ نوشتن کد جدید بروید، باگ‌های موجود را برطرف کنید.
گرچه ممکن است رویکرد رفع باگ به صورت پیوسته، بدیهی به نظر برسد اما واقعیت این است که خیلی اوقات فراموش می‌شود. تصور ما این است که می‌توانیم حوزه تاثیر باگ‌ها در کل نرم‌افزار را کنترل کنیم. بنابراین همیشه به دنبال تمام کردن کد هستیم و بعد رفع باگ‌های آن. این یک روش اشتباه است.
جوئل اسپالسکی برای اثبات نظرش در این خصوص مثال تولید نسخه اولیه word تحت ویندوز را می‌زند که پروژه بارها و بارها و بارها از زمان‌بندی عقب ماند و در نهایت هم یک محصول معیوب وارد بازار شد. در واقع مدیران پروژه مایکروسافت بیشتر روی زمان‌بندی انجام شده و deadline ها تاکید داشتند که پروژه به زمان‌بندی برسد و زمانی برای bug fix در نظر نگرفته بودند. نتیجه چه شد؟ به گفته جوئل روایت شده یکی از برنامه‌نویسان که مسئول نوشتن تابع محاسبه ارتفاع خط بود در کد تابعش فقط نوشته بود return 12 و منتظر مانده بود که بالاخره یکی گزارش باگ بفرستد که این تابع همیشه درست کار نمی‌کند!
به روش فوق "متدولوژی عیوب نامحدود" یا infinite defects methodology گفته می‌شود. در مقابل مایکروسافت روش "متدولوژی بی عیب" یا zero defects methodology را پی گرفت. در این متدلوژی بالاترین اولویت در توسعه نرم‌افزار در هر زمان رفع عیوب جاری است. جوئل دلیل این کار را چنین بیان می‌کند: "هر چه برای تصحیح یك اشكال بیشتر معطل كنید، هزینه تصحیح آن (از لحاظ وقت و پول) بیشتر خواهد بود."
اسکای نت اولش فقط یک سیستم هوش مصنوعی دفاعی بود، احتمالاً یک باگ نرم‌افزاری باعث شد ترمیناتور‌ها رو بفرسته تا بشر رو نابود کنند. نتیجه اخلاقی: باگ‌های نرم‌افزاری ممکنه ما رو دچار مشکلات جدی بکنند!
استدلال جوئل در این خصوص منطقی است. شما امروز اشکالات کدی که نوشتید را به یاد دارید، اما اگر مثلاً 6 ماه دیگر بگویند فلان
اشکال در کد شما به وجود آمده پیدا کردن دلیل و حل آن زمان‌بر و مشکل است. حالا فرض کنید که به شما کد نوشته شده توسط یک نفر دیگر را داده‌اند و می‌گویند اشکالش را برطرف کن!
در واقع اگر هر یک از اعضای تیم نرم‌افزاری در نوشتن کد با توجه به شعار متدولوژی بی عیب، اولویت را به رفع همه اشکالات منطقی موجود بدهد، حتی اگر در آینده شخص دیگری روی توسعه این کد کار کند، احتمال شکست یا بروز باگ در آن پایین است. بر این اساس است که مفاهیمی چون white bug بی معنی می‌شوند و شما موظف می‌شوید کد با کمترین احتمال اشکال را check in کنید. پیدا کردن اشکال در کد check in شده آن هم بعد از گذشت مدت طولانی واقعاً می‌تواند تبدیل به یک فاجعه برای تیم بشود.
مزایای متدولوژی بی عیب
جوئل 2 مزیت عمده برای متدولوژی بی عیب ذکر می‌کند:
1- استفاده از این متدولوژی باعث افزایش دقت در برنامه‌ریزی تیم شما می‌شود. به بیان جوئل "اگر در برنامه زمان‌بندیتان تعداد زیادی باگی كه باید رفع شوند، وجود داشته باشد، زمان‌بندیتان غیر قابل اعتماد است. اما اگر تمامی ایرادهای شناخته شده را تصحیح كرده‌اید و فقط كد جدید مانده، زمان‌بندیتان به طرز حیرت آوری دقیقتر خواهد بود."
2- عکس العمل سریع در برابر رقبا: اگر رقیب شما یک امکان جدید به نرم‌افزارش اضافه کند، شما هم در کمترین زمان و با خیال راحت می‌توانید آن ویژگی را به محصولتان اضافه کنید چرا که اطمینان دارید افزودن این ویژگی باعث اضافه شدن به مجموعه‌ای از اشکالات کهنه نمی‌شود.
اما به گمان استفاده از این روش مزیت دیگری نیز در پی دارد: چیزی که من اسمش را می‌گذارم پختگی نرم‌افزار.استفاده از متدولوژی بی عیب باعث افزایش آهنگ پخته شدن نرم‌افزار می‌شود. منظور من از نرم‌افزار پخته نرم‌افزاری است که stable شده و هدف تیم توسعه آن در نسخه‌های بعدی بیشتر افزودن به قابلیت‌های نرم‌افزار است تا bugfix. از این نظر وقتی شما مثلاً نرم‌افزاری مثل مرورگر کروم را نگاه می‌کنید می‌بینید از همان نسخه‌های اولیه روند پخته شدن نرم‌افزار با شتاب ادامه یافته است. در واقع بر بستر یک کد خوب و بی عیب، به تدریج امکانات و قابلیت‌های نرم‌افزار گسترش یافته است.