إذا لم يكن قابلاً للتسليم فهو غير مكتمل

يُعلَن انتهاء البرمجيات عادة عند نجاح اختبار القبول. وهي محطة تجارية معقولة ومحطة هندسية سيئة، لأنها تقيس النظام في اليوم الذي لا يزال فيه من بناه في الغرفة.

والاختبار الأنفع هو اختبار التسليم: هل يستطيع مهندس كفؤ لم يتحدث إلينا قط أن يُجري تغييراً آمناً على هذا النظام بالاعتماد على المكتوب وحده؟ ليس تغييراً بطولياً، بل تغييراً روتينياً، يوم ثلاثاء، دون مكالمة هاتفية.

ومعظم الأنظمة تفشل في هذا الاختبار، وتفشل في مواضع متوقعة. تهيئة بيئة تسكن في سجل أوامر شخص ما. خطوة نشر موثقة تقنياً لكن لها شرط ترتيب غير مذكور. قواعد عمل صحيحة في الكود وغير مشروحة في أي مكان، فلا يستطيع المهندس التالي أن يميّز حالة استثنائية مقصودة من خطأ.

والتعامل مع التسليم كمتطلب لا كمرحلة يغيّر ما يُبنى. تصبح التهيئة سكربتاً لأن السكربت هو التوثيق الوحيد الذي لا ينحرف. وتحصل القرارات المعمارية على سجل مكتوب قصير بما اختير وما رُفض، وهو ما يحتاجه المهندس الجديد فعلاً. وتُكتب الاختبارات حول قواعد العمل تحديداً لتصمد القاعدة أمام من لا يفهمها.

ولا شيء من هذا مكلف في وقته، وكله مكلف عند إضافته لاحقاً، ولهذا لا يُضاف لاحقاً تقريباً أبداً، ولهذا تخاف مؤسسات كثيرة من أنظمة تملكها.

ونحن نلزم أنفسنا بذلك لسبب أناني أيضاً: بديل النظام القابل للتسليم هو عميل يعتمد علينا. وهذا عمل أسوأ من عميل يبقى لأن العمل جيد.