Get best of the week

لماذا نكتب برامج ذات نوعية رديئة؟


:
— , ,  — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
- يقولون أن الموثوقية مضمونة بتقنية تسمى blockchain.
- Ahhhhhhhh !!! مهما يقولون ، لا تلمسها! أحفر أكثر عمقا. لا تنس القفازات!
المصدر: XKCD ، ترخيص Creative Commons 2.5.

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

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

تابع تويتر موجة من علامات التصنيف #app و # المشاكل ، واستشهد مهندسو البرمجيات بـ KDPV. فكرت بذلك أيضا. الكلمات من هذا الكارتون تلخص بشكل عام الشعور العام بما يحدث: "أنا لا أعرف تمامًا كيف أعبر عنه ، لكن منطقتنا بأكملها سيئة في ما نقوم به ، وإذا كنت تعتمد علينا ، فسوف يموت الجميع." لا يقول مهندسو البرمجيات ذلك مباشرة. لكنها تبدو متشابهة للغاية. ماذا نعني؟

إليك ما نعنيه: نحن نقوم بالبرامج بشكل جيد ، شريطة ألا تكون عواقب الفشل مهمة. في المتوسط ​​، البرامج جيدة بما يكفي للعمل بطريقة أو بأخرى. ومع ذلك ، فإننا لا نفاجأ بشكل خاص بالأخطاء في معظم البرامج. هذه ليست بعض الحوادث النادرة. تأتي العديد من الممارسات الشائعة في هندسة البرمجيات من افتراض أن الأعطال هي القاعدة ، والأهم من ذلك ، الميزات الجديدة. الفشل رخيص حقا. إذا كانت الخدمة عبر الإنترنت من إحدى أكبر الشركات غير متصلة تمامًا لمدة ساعتين ، فسوف ينسون ذلك في غضون أسبوع. يتجسد هذا الافتراض في العبارات الشائعة: "تحريك سريع وكسر كل شيء" (تحريك سريع وكسر الأشياء) ، "طرح وتكرار الدورة" (الإطلاق والتكرار).

يكافئ السوق بسخاء لمثل هذا السلوك "غير المسؤول". في العديد من شركات الويب ، يتم ضرب ربح صغير لكل مستخدم في الملايين (أو المليارات!) من المستخدمين. هذا مفيد للشركات التي لديها تطبيقات أو مواقع ويب للمستهلكين. التنفيذ مكلف ، لكن التكلفة محدودة ، والتوزيع مجاني تقريبًا. لقد وجدت صناعة البرمجيات الاستهلاكية حلاً وسطًا: نحن نخفض معدل التنفيذ بما يكفي للحفاظ على مستوى العيوب لدينا منخفضًا إلى حد ما ، ولكن ليس كثيرًا.

نحن نسمي تطوير البرمجيات هذا "النموذج الاقتصادي لموقع الويب": عندما تكون فوائد التطبيق عالية وتكلفة إعادة المحاولة منخفضة ، تشجع الإدارة على إطلاق الوظائف بسرعة عالية. ينعكس هذا في الممارسات الحديثة لإدارة المشاريع وتنفيذها ، والتي سأناقشها أدناه.

ولكن ، كما قلت ، "نحن نقوم بالبرمجيات جيدًا ، شريطة ألا تكون عواقب الفشل مهمة". يؤدي هذا النهج إلى إخفاقات رهيبة إذا كانت العواقب ليست رخيصة ، كما هو الحال في ولاية ايوا. نمت الممارسة الشائعة لتطوير البرمجيات من النموذج الاقتصادي للإنترنت ، وعندما تنتهك افتراضات هذا النموذج ، يقوم مهندسو البرمجيات بعمل ضعيف.

كيف تعمل البرمجة في شركات الويب؟


تخيل الشركة الافتراضية QwertyCo. إنها شركة برمجيات موجهة نحو المستهلك تحقق 100 مليون دولار في السنة. يمكننا تقدير حجم QwertyCo عن طريق المقارنة مع الشركات الأخرى. وصلت WP Engine ، استضافة WordPress ، إلى 100 مليون دولار ARR في 2018 . حقق Blue Apron 667 مليون دولار لهذا العام . وبالتالي ، QwertyCo هي شركة متوسطة الحجم. لديها من عدة عشرات إلى عدة مئات من المهندسين ولم تقم بإصدار أسهم في التداول العام.

أولاً ، ضع في اعتبارك اقتصاديات إدارة المشاريع في QwertyCo. لقد تعلم القادة أنك لا تريد الإعلان على الفور عن ميزة جديدة. لديك حل وسط بين جودة البرنامج والموعد النهائي وسرعة التنفيذ.

ما مدى أهمية جودة البرمجيات بالنسبة لهم؟ ليس صحيحا. إذا كان موقع QwertyCo معطلًا لمدة 24 ساعة في السنة ، فإنهم يقدرون الخسارة بمبلغ 273.972 دولارًا فقط (بافتراض أن وقت التشغيل مرتبط خطيًا بالإيرادات). يقولون أن الموقع غالبًا ما يكون غير متصل بالإنترنت لمدة 15 دقيقة ، ولا أحد يهتم حقًا. إذا تعطلت الوظيفة في الموقع ، فسوف يعيدها ويحاول مرة أخرى لاحقًا. المحاولات المتكررة رخيصة.

ما مدى أهمية الميزة الجديدة لـ QwertyCo؟ بناءً على ملاحظاتي الشخصية ، فإن شهر واحد من عمل مهندس واحد قادر على تغيير دخل موقع محسن في النطاق من −2٪ إلى 1٪. هذه فرصة شهرية للحصول على مليون دولار من عائدات QwertyCo الإضافية لكل مهندس. طرق مثل اختبار A / B حتى تخفف من الأخطاء: في غضون بضعة أسابيع ، يمكنك اكتشاف التغييرات السلبية أو المحايدة وإزالة هذه الميزات. الخصائص السيئة رخيصة - فهي نشطة لفترة زمنية محدودة. يتم الحصول على الفوز إلى الأبد. حتى نسبة منخفضة من الرهانات الفائزة تحقق ربحاً من QwertyCo.

بالنظر إلى الإيجابيات والسلبيات ، متى يجب على QwertyCo إصدار وظيفة؟ يظهر الحساب الاقتصادي أنه حتى الوظائف عالية المخاطر يجب أن تبدأ إذا كانت تحقق ربحًا في بعض الأحيان. وفقًا لذلك ، يتحول كل مشروع إلى لعبة تحسين: "كم يمكن تنفيذه بحلول هذا التاريخ؟" ، "كم من الوقت مطلوب لتنفيذ المشروع بأكمله؟ ماذا لو قمت بإزالة X منه؟ ماذا لو قمت بإزالة X و Y؟ كيفية تسريع تنفيذ جزء معين؟ "

الآن فكر في مشروع برمجيات من وجهة نظر مهندس برمجيات.

مصدره الرئيسي هو الوقت. يستغرق تطوير البرامج الآمنة وقتًا طويلاً. بمجرد أن يتخطى المنتج حدًا معينًا من التعقيد ، فإنه يحتوي على عدة مراحل من التطور (حتى لو لم يمر كجزء من عملية صريحة). يجب أن يتم التخطيط لها بمساعدة مدير المنتج. يتم تحويل المنتج إلى مشروع أو خطة فنية ، إذا لزم الأمر ، ينقسم إلى مهام فرعية. ثم يتم كتابة رمز مع الاختبارات ، ويتم إجراء مراجعة الرمز ، ويتم تسجيل الإحصائيات ، ويتم دمج المنتج مع لوحات المعلومات والتنبيهات. إذا لزم الأمر ، يتم إجراء الاختبار اليدوي. بالإضافة إلى ذلك ، غالبًا ما يحتوي الترميز على عبء إضافي يعرف باسم إعادة البناء.: تعديل نظام موجود لتسهيل تنفيذ ميزة جديدة. في تنفيذ الوظيفة "الصغيرة" ، لا يمكن أن يستغرق الترميز نفسه سوى 10-30٪ من الوقت.

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

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

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

وبالتالي ، فإن للإدارة والتنمية وجهات نظر متعارضة بشأن الجودة. يوافق الدليل على معدل خطأ مرتفع (ولكن ليس مرتفعًا جدًا) ، ويريد المهندسون أن يكون الخطأ هو الحد الأدنى المطلق.

كيف يؤثر ذلك على إدارة المشروع؟ يقسم المدراء والمطورون المشروع إلى مهام صغيرة. يعتمد وقت تنفيذ المشروع على عدد المهام وعدد المهندسين. غالبًا ما يستغرق المشروع وقتًا طويلاً - ويتم تعديله عن طريق إزالة الوظائف. ثم يقوم المهندسون بتنفيذ المهام. غالبًا ما يتم تنفيذ المهمة داخل العدو.. إذا كان وقت الركض أسبوعين ، فإن كل مهمة تحتوي على مؤقت أسبوعي ضمني. ومع ذلك ، غالبًا ما تستغرق المهام وقتًا أطول مما تعتقد. يتخذ المهندسون قرارات صعبة لتحديد الأولويات لإنهائها في الوقت المحدد: "يمكنني القيام بذلك بحلول نهاية السباق السريع إذا كتبت اختبارات أساسية وإذا تخطيت إعادة البيع كنت أخطط." تمارس العدو ضغطًا مستمرًا ، مما يدفع المطور. وهذا يعني أنه يمكن للمهندس إما التنازل عن الجودة أو الاعتراف بالفشل في الاجتماع التالي.

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

بعد وضع هذه الحوافز ، يحصل المدير على ما يريد: يمكنه تسمية الوظيفة والتاريخ المستقبلي ، وستناقش الإدارة والمطورين كيفية القيام بذلك. "أريدك أن تقوم بعمليات شراء بنقرة واحدة خلال شهرين دون إنشاء حساب." سيكتب المديرون والمطورون جميع المهام لمدة أسبوعين وسيختصرون القائمة حتى يتمكنوا من تشغيل الوظيفة المسماة "عمليات الشراء بنقرة واحدة". سيكون لديها خطر معتدل من الفشل ، وستعمل على الأرجح فقط بعد بضع تكرارات. لكن الفشل مؤقت ، والوظيفة إلى الأبد.

ماذا يحدث إذا انتهكت افتراضات مثل هذا النموذج الاقتصادي؟


كما قلت ، نقوم بعمل البرامج جيدًا ، بشرط ألا تكون عواقب الفشل مهمة. يشار إلى ذلك من خلال شعارات "تحرك بسرعة وكسر كل شيء" ، "طرح وتكرار". ولكن يمكن للجميع أن يتخيلوا وضعًا تكون فيه إعادة التصنيع باهظة الثمن أو حتى مستحيلة. إن انهيار مبنى قد يقتل آلاف الأشخاص ويسبب أضرارا بمليارات الدولارات. يعد مؤتمر الفصائل في ولاية أيوا 2020 مثالاً أخف. إذا فشل الحدث ، في المساء سيعود الجميع إلى المنزل على قيد الحياة. لكن الحزب لا يستطيع تنظيم هذه اللقاءات للمرة الثانية ... دون إنفاق الكثير من الوقت والمال والجهد.

ملاحظة مختصرة: في هذا القسم ، استخدم عبارة "عالية المخاطر" كاختصار لـ "المواقف مع استحالة إعادة المحاولة" و "المواقف التي تنطوي على إمكانية مكلفة لإعادة المحاولة".

ماذا يحدث عندما يتم تطبيق نموذج موقع اقتصادي في حالة عالية المخاطر؟ لنأخذ مثالاً عشوائيًا: لنفترض أنك تكتب طلبًا للإبلاغ عن نتائج اجتماع في ولاية آيوا. ما هي الخطوات التي ستتخذها لكتابة الطلب واختباره واختباره؟

أولاً ، اللوجستيات الهندسية: يجب عليك كتابة تطبيق Android وتطبيق iPhone. يعد إعداد التقارير مطلبًا مركزيًا ، لذا يلزم وجود خادم. يجب ترميز قواعد المجموعة المربكة على كل من العميل والخادم. يجب أن يبلغ النظام النتائج إلى المستخدم النهائي ؛ هذه واجهة أخرى يجب برمجتها. ربما يكون للحزب الديمقراطي متطلبات التحقق والإبلاغ التي يجب أن تكتبها إلى التطبيق. بالإضافة إلى ذلك ، سيكون من غير المناسب للغاية إذا فشل الخادم أثناء الاجتماع ، لذلك تحتاج إلى تنفيذ نوع من نظام المراقبة.

بعد ذلك ، كيفية التحقق من التطبيق؟ أحد الخيارات هو اختبار المستخدم. يمكنك عرض صور لتطبيق افتراضي للمستخدمين المحتملين - وطرح أسئلة مثل "ما رأيك في هذه الشاشة؟" و "إذا كنت تريد الوصول إلى $ a_thing ، فأين ستنقر؟" يتطلب التصميم دائمًا عدة تكرارات ، لذا فمن المعقول توقع جودة عالية بعد عدة جولات من هذا الاختبار. غالبًا ما تقضي الشركات الكبيرة عدة جولات قبل تقديم ميزات مهمة. في بعض الأحيان يقومون حتى بإلغاء الوظائف بعد تلقي الملاحظات قبل كتابة سطر واحد على الأقل من التعليمات البرمجية. اختبار المستخدم رخيص. هل من الصعب العثور على خمسة أشخاص سيمضون 15 دقيقة في الاستبيان ، بعد أن حصلوا على بطاقة هدية مقابل خمسة دولارات كهدية؟ في حالتنا ، أصعب شيء هو صنع عينة تمثيلية ،الذي يتوافق مع الممثلين الديمقراطيين لولاية أيوا.

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

علاوة على ذلك ، الإنترنت مليء بالأشرار. على سبيل المثال ، نشرت الجماعات الروسية معلومات مضللة على نطاق واسععبر وسائل التواصل الاجتماعي مثل Facebook و Reddit و Twitter. لذلك ، تحتاج إلى التأكد من عدم تدخل أي شخص آخر. كيف تتحقق من صحة النتائج؟ بالإضافة إلى الأشرار ، فإن الإنترنت مليء بالمهرجين المستعدين لتعطيل أي حدث لمجرد التسلية . كيف يقاوم نظامنا هجمات DDoS؟ إذا لم يكن الأمر كذلك ، فهل هناك خطة احتياطية؟ من المسؤول عن تقديم خطة احتياطية من خلال الإبلاغ عن ذلك في الاجتماعات؟ ماذا يحدث إذا تم اختراق حسابات الأعضاء؟ إذا لم يكن لدى الشركة خبراء أمنيين ، فمن المحتمل أن يخضع التطبيق لتدقيق مستقل.

علاوة على ذلك ، كيف تضمن عدم وجود خطأ في البرنامج من شأنه أن يشوه النتائج؟ وبناءً عليه ، يجب أن يشك الحزب الديمقراطي في نفسه: هل من الممكن تصديق النتائج إذا كان هناك خائن في صفوفه؟ يجب أن تكون النتائج متاحة للتحقق باستخدام النسخ الورقية.

حسنًا ، دعنا نتوقف عن إدراج المشكلات. شيء واحد واضح: يستغرق الأمر الكثير من الوقت والموارد للتأكد من أن كل شيء يعمل.

تم منح مبدعي تطبيق Iowa Caucus 60000 دولار وشهرين. كان لديهم أربعة مبرمجين. هذا المبلغ لا يكفي لدفع أربعة مبرمجين جيدين ونفقات أخرى. لا يمكن استبدال المال بالوقت. عمليا ليس هناك مساعدة خارجية.

تخيل أنك تستخدم الممارسة المقبولة عمومًا لإزالة المهام من مشروع حتى يصبح الجدول الزمني ممكناً. سوف تبذل قصارى جهدك لتوفير الوقت. غالبًا ما تستغرق معاينة كتالوج التطبيق أقل من يوم ، ولكن في أسوأ الأحوال ، يمكن أن تستمر أسبوعًا ، وقد يتم رفض التطبيق. لذلك دعونا نتخطى هذا: سوف يقوم الأعضاء الديمقراطيون بتنزيل التطبيق عبر روابط بيتا. حتى مع إجراء فحص أمني مجاني ، سيستغرق الأمر وقتًا طويلاً لتنفيذ جميع توصياتهم. لذلك ، نرفض التحقق الأمني. ربما ، أثناء تطوير الواجهة الخلفية ، دفعت للمصمم 1000 دولار لإنشاء تخطيط التطبيق والشعار. كنت تخطط لجولة واحدة من اختبار المستخدم (ولكن تخطيها عند حلول المواعيد النهائية).طرحها بسرعة وتكرار الدورة! يمكن إصلاح كل شيء دائمًا.

والبرمجة تستغرق دائمًا وقتًا أطول من المتوقع! سوف تواجه المقابس. أولاً ، قواعد عقد الاجتماعات ليست واضحة تمامًا. يتضح دائمًا عندما يتم فرض حل رقمي على العالم التناظري. يمكن للعالم الحقيقي أن يتصالح مع الغموض وعدم الاتساق ، لكن العالم الرقمي لا يستطيع ذلك. رداً على أسئلتك ، ستقوم لجنة الحزب الديمقراطي بإعداد توضيحات. هذا سيعيقك. يجوز للجنة أيضا تغيير القواعد في الثانية الأخيرة. سيؤدي ذلك إلى تغيير التطبيق قبل الموعد النهائي مباشرة. بعد ذلك ، لديك العديد من المطورين ، مما يعني زيادة التنسيق. هل كل برنامج تشفير ضليع 100٪ في الهاتف المحمول ،وفي تطوير الخادم؟ هل جميعهم يتقنون React Native بشكل مثالي؟ شبيبة؟ مخطوطة؟ اتصالات خادم العميل؟ ما هي الأطر والمكتبات التي اخترتها؟ يضيف كل "لا" وقتًا للتطوير ليأخذ في الاعتبار التنسيق والتدريب. هل الجميع سعداء بإطارات الاختبار التي تستخدمها؟ أنا فقط أمزح. ما هي الاختبارات الموجودة ... نعم ، في البداية كتبوا اختبارين ، لكن التطبيق تغير بسرعة كبيرة بحيث تم حذفهم.

الوقت لا ينتظر. لقد انقضى شهران - يمكنك الوصول إلى خط النهاية بجهد أخير وإطلاق الإصدار النهائي.

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

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

الموجودات


ساعدني هذا المقال شخصيًا على الاستنتاج: عند التخطيط لمشروع ، تحتاج إلى إضفاء الطابع الرسمي على تكلفة التعديل. لقد فعلت ذلك بشكل حدسي في الماضي ، ولكن يجب أن يكون ملموسًا بشكل ملموس. يساعد هذا الشكل الرسمي على فهم المهام التي لا يمكن أن تفشل في أي حال. يبدو الأمر كما لو كان في الروبوتات المحمولة الخاصة بي: هناك دورات تنفيذ طويلة ، ويمكن أن يمر الضرر الناتج عن خلل في السقف. لقد أمضينا الكثير من الوقت في تطوير المراقبة وإنشاء طرق موثوقة لقمع وإيقاف الأنظمة الخارجة عن السيطرة. أنا أعمل أيضًا مع خدمات الويب للمستهلكين لمدة عشر سنوات ، حيث تكون عواقب الفشل أقل. هناك استعداد أكبر لتحمل ديون قصيرة الأجل والمضي قدمًا مع خطر الفشل المؤقت ، خاصة عندما يكون التراجع رخيصًا وفقدان البيانات غير مرجح. على الأقل ، تدفع المحفزات لمثل هذا السلوك فقط.هناك تقنيات خاصة في صناعتنا لمنع مثل هذه المشاكل. واحد منهم -التحقيق في حالات الفشل الخيالي (قبل الوفاة). تحتاج إلى القيام بذلك في كثير من الأحيان.

فشل ايوا له نتيجة إيجابية. أدرك البعض غير المرتبط بتكنولوجيا المعلومات وجود أخطاء في البرامج. في السنوات المقبلة ، سيبدأ رعاة تطوير التطبيقات للأحزاب السياسية في التساؤل: "ما الذي يضمن عدم تكرار الوضع مع الكونغرس من الكسور في ولاية أيوا؟" ربما سيتعرفون على الأدب ، الذي يحاول تعليم المديرين كيفية العمل بشكل صحيح مع المهندسين. على سبيل المثال ، لدى وزارة الدفاع الأمريكية دليل بعنوان "كيفية التعرف على المشاريع المزيفة الرشيقة" ، والذي يصف العلامات المشبوهة حول العقد. تمتلئ منتديات الشركات الناشئة من غير التقنيين الذين يطلبون (ويحصلون) على نصائح حول توظيف المطورين.

لم تتعلم صناعة تكنولوجيا المعلومات أي شيء. أتاح مؤتمر فصيل ولاية أيوا فرصة لدراسة كيف أن افتراض "ارتفاع تكلفة الخطأ" سيغير عملياتنا الأساسية. لكننا لم ننتهز هذه الفرصة ولم نستخرج منها أي شيء. لا تهتم صناعة البرمجيات الاستهلاكية بمخاطر الأخطاء. في الواقع ، نحن سعداء بالأخطاء. إذا كان العالم الخارجي مهتمًا بتحسين جودة الشفرة في مناطق معينة ، فيجب عليهم تنظيم هذه المناطق. لن تكون هذه المرة الأولى. قانون Sarbanes - Oxley و HIPAA أمثلة على التنظيم في تطوير نموذج اقتصادي لموقع ويب. التنظيم ليس كافيًا ، ولكن قد يكون ضروريًا.

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

More articles:


All Articles