เครื่องมือของผมปฏิเสธงานผมเอง 4 ครั้งในวันเดียว

นักพัฒนาหลายคนมักมีความคุ้นเคยกับการรันชุดทดสอบให้ผ่านแล้วจึงส่งมอบงาน แต่มีสักกี่คนที่เคยสร้างการตรวจสอบที่ต้องสั่งห้าม และพิสูจน์ให้เห็นว่ามันเคยปฏิเสธงานจริงๆ เสียก่อน สำหรับนักพัฒนาซอฟต์แวร์รายหนึ่ง ประสบการณ์การทำงานในหนึ่งวันเต็มได้เปลี่ยนมุมมองนี้ไปอย่างสิ้นเชิง เมื่อเครื่องมือที่เขาพัฒนาขึ้นเองได้ปฏิเสธโค้ดของเขาถึง 4 ครั้งติดต่อกัน จนกระทั่งเขาต้องจดบันทึกรูปแบบความผิดพลาดที่เกิดขึ้นซ้ำๆ เหล่านี้

ความผิดพลาดทั้งสี่ครั้งต่างสวมชุดที่แตกต่างกันออกไปแต่มีแก่นเดียวกัน นั่นคือการนำเอาผลลัพธ์ที่เครื่องมือผลิตออกมาไปตีความว่าเป็นหลักฐานของคำถามอีกข้อหนึ่ง โดยครั้งแรกเขาทำการสแกนเน็ตเวิร์กเพื่อหาบริการและเจอสิ่งที่ตอบรับ จึงด่วนสรุปว่าบริการนั้นอยู่ตรงนั้น ทั้งที่ความจริงเป็นกระบวนการตกค้างจากโมเดลเก่า ส่วนครั้งที่สองเขาอ่านข้อความแจ้งข้อผิดพลาดจากบันทึกเดิมและเกือบจะเขียนโค้ดแก้ซ้ำซ้อนกับสิ่งที่เคยแก้ไขไปแล้วถึงสามวันก่อนหน้า

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ในกรณีที่สาม ลูปการตรวจสอบของเขารายงานว่าไฟล์ทดสอบผ่านสองไฟล์กลับกลายเป็นล้มเหลว เพียงเพราะตัวระบบค้นหาข้อความคำว่า red ในเอาต์พุต และคำในภาษาเยอรมันที่แปลว่าอย่างไรก็ตามดันมีตัวอักษรสามตัวนั้นซ่อนอยู่ภายใน และครั้งสุดท้ายคือการเพิ่มไฟล์ลงในการสร้างระบบโดยลืมใส่ชื่อไฟล์ลงในรายการ ผลลัพธ์คือการสร้างรายงานว่าสำเร็จแต่แพ็กเกจที่ได้กลับพังทลายทันทีเมื่อรันคำสั่งแรก เหตุการณ์เหล่านี้สะท้อนช่องว่างระหว่างคำถามในหัวกับสิ่งที่ระบบรายงานออกมาจริง ซึ่งเป็นจุดที่เวลาทำงานทั้งวันมักจะสูญเสียไปอย่างเงียบๆ

บทเรียนสำคัญที่ต้องใช้เวลานานมากกว่าจะยอมรับได้คือ สำหรับเกราะป้องกันทุกอันที่เขียนขึ้น เรามักจะบอกได้ว่ามันผ่าน แต่ส่วนใหญ่แล้วเราไม่เคยเห็นมันล้มเหลวเลยสักครั้ง เกราะป้องกันที่ไม่เคยลิ้มรสความล้มเหลวก็เป็นเพียงแค่ของประดับตกแต่งที่บังเอิญมีสีที่ถูกต้อง และมันจะยังคงแสดงสีเดิมต่อไปแม้ว่าระบบจะพังไปแล้วก็ตาม ดังนั้นการยอมรับเกราะป้องกันจึงต้องมี 2 กรณีและลำดับมีความสำคัญอย่างยิ่ง โดยต้องพิสูจน์ให้ได้ก่อนว่ามันเอ่ยคำว่าไม่ในเวลาที่ควร แล้วจึงพิสูจน์ว่ามันเอ่ยคำว่าใช่ในเวลาที่ควรเช่นกัน