البرمجيات التي تبقى داخل المتصفح تستطيع افتراض أشياء مريحة كثيرة. تستطيع افتراض أن الأشياء تستجيب سريعًا وتفشل بوضوح وتتصرف غدًا كما تصرفت اليوم. أما البرمجيات التي تتحدث مع معدات مادية فلا تستطيع افتراض أي من ذلك.
الأجهزة تفشل بطرق لا تفشل بها الواجهات البرمجية
- مطفأ، أو يعمل لكنه غير جاهز
- يستجيب ببطء بدل أن يفشل
- يعيد نتيجة العملية السابقة
- فُصل ماديًا وأُعيد وصله في منتصف الجلسة
- حُدِّثت برمجيته ليلًا بسلوك مختلف قليلًا
كل حالة من هذه تحتاج قرارًا صريحًا لما يفعله النظام. والافتراض الشائع «أعد المحاولة وتمنَّ» يُنتج سجلات مكررة — طابعة طبعت ولم تُقر، ونتيجة محلّل نُسبت إلى العينة الخطأ.
حِزم تطوير المصنّعين هي الواجهة الحقيقية
العمل مع حزمة تطوير من مصنّع تخصص مختلف عن استهلاك واجهة ويب. التوثيق غالبًا شحيح، والسلوك يُكتشف بالتجربة، والتجريد يتسرّب. ويستغرق وقتًا تقلّل التقديرات من شأنه باستمرار، وهو عمل لا يمكن توزيعه بإضافة أشخاص.
وقاعدتنا العملية أن تكامل الأجهزة يُجدوَل كعمل هندسي أساسي بهامش مخاطرة خاص به، لا كمهمة في نهاية الخطة.
البيئة ليست مركز بيانات
شاشات الانتظار في أماكن عامة. وطابعات التذاكر ينفد ورقها. ومعدات التصوير على شبكة مستشفى بقيودها الخاصة. ويجب أن يكون البرنامج قابلًا للتشغيل ممن هو حاضر ماديًا، وهو عادةً شخص بلا خلفية تقنية وبلا وقت.
إذا كان التعافي من عطل جهاز يتطلب حضور مهندس، فالتصميم فشل بالفعل.
ولماذا نفعله رغم ذلك
لأن البديل شخص ينسخ. فأينما أُعيد إدخال مخرجات معدات في نظام يدويًا — نتيجة معملية أو مرجع دراسة تصوير أو قياس — يكون ذلك النسخ أعلى الخطوات خطورة في العملية كلها، وهو قابل للتجنب تمامًا.
تكامل الأجهزة عمل غير براق وبطيء وصعب التقدير. وهو أيضًا النقطة التي يتوقف عندها البرنامج عن كونه طبقة إدارية ويبدأ في إزالة العمل فعلًا.