مصمّمون خلف الستار. مشكلة( Y2K )

2014 لنسامح التصميم

هنري بيتروكسكي

مؤسسة الكويت للتقدم العلمي

التكنولوجيا والعلوم التطبيقية الهندسة

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

اختصار السنوات لم يكن أمراً جديداً. فقبل ظهور الحواسيب الإلكترونية بزمن طويل، اعتاد التجار والزبائن، على حدٍّ سواء، على فوائد استخدام مرتبتين للسنين. فالعديد من قسائم الأعمال التي كانت تستخدم في القرن التاسع عشر استعملت التاريخ مكتمل جزئياً: ______ __ ،18__. [شهر يوم، سنة]، وما على الكاتب إلّا ملء الشهر واليوم ومرتبتين من السنة، وعادة ما أعيد طلب هذه القسائم والقرن الجديد يقترب، لكن إن بقيت كمية كبيرة من هذه القسائم القديمة فقد يستمرّ استخدامها بعد شطب الرقم "8" وكتابة السنة بثلاث مراتب. واستخدمت المختصرات والأرقام عموماً للدلالة على الأشهر، موفرين وقتاً إضافياً وغرافيت [توفيراً لاستهلاك الأقلام المستخدمة في الكتابة]، حتى عندما لم يكن هناك قسائم مطبوعة مسبقاً.

يعتبر استخدام الأرقام والخطوط المائلة للدلالة على التاريخ سلوكاً عاماً مستخدماً من زمن طويل، لذا [فالتاريخ] أيلول/ سبتمبر 7، 1939 يصبح 9/7/1939 [على الطريقة الأميركية]. وتسلسل الشهر واليوم قد يختلف، حيث يفضل الأميركيون شهر/ يوم بينما يفضل الأوروبيون يوم/ شهر، ولكن بصورة عامة كان كل شخص مدركاً في أية قارة هو، وبالتالي كان يفهم المعنى المقصود، وبمثل هذا الاستخدام الشائع والكفؤ، هل كان متوقّعاً من مبرمجي الحواسيب ومستخدميها الشكّ في حكمة نقل استخدام السنة بمرتبتين [يدوياً] إلى عصر الحاسوب [الآلي]؟ والذين تساءلوا عن ما قد يحدث في بداية قرن جديد مالوا إلى طرد الفكرة من أذهانهم بمبرّر أنه لن يطول استخدام برامجهم [لحين ذلك] من دون إبدالها بنسخ أحدث، أو أن برمجيات ومعدات الحاسوب قد تتطوّر متجاوزة الحاجة للقلق حول نقطة تافهة كهذه.

بالطبع، عندما اقتربت السنة 2000، أيقن كل مسؤول عن خزن البيانات المحوسبة، والحسابات المالية والإجراءات الإلكترونية أن مشكلة محتملة تبانُ في الأفق، وكما كان متوقّعاً، وبالرغم من تطور الحواسيب وبرمجتها، استمر استخدام العديد من البرامج [التطبيقية] القديمة لما بعد تاريخ نفاذها الضمني.

فقد استمرت هذه البرامج في حساب فرق الزمن بين تاريخين من خلال عملية طرح بسيطة، تتضمّن طرح رقم ذي مرتبتين من آخر، وجرت هذه العملية من دون أخطاء طوال معظم النصف الأخير من القرن العشرين، وواضح أن أرباكاً قد يحدث داخل الجهاز، في أحسن الأحوال، عندما يصادف [البرنامج] الأرقام 99 و00 ، لتمثيل 1999 و2000. فطرح الأول من الثاني سينتج منه رقم سالب لعدد السنين لم تُبرمج الحواسيب للتعامل معه.

إصلاح ما أصبح يطلق عليه مشكلة العام 2000 أو (Y2K) قد تبدو سهلة: فما كان على المبرجمين إلا الرجوع إلى برامج الحاسوب المتأثرة [بالتاريخ] وتبديل مرتبتي السنوات في الخوارزميات المعنية إلى سنوات بأربعة مراتب. لكن العديد من البرامج المالية كانت قد كتبت في بعض من أقدم لغات البرمجة – قد تم تجاوزها، مثل لغة كوبول (Common Business Oriented language – COBOL)، ولأن جيل الشباب من المبرمجين الملمّين بمثل هذه اللغات كان قد تناقص بشكل مستمرّ، فقد اضطر الحال إلى إعادة العديد من المبرمجين المتقاعدين إلى الخدمة كاستشاريين. إضافة إلى ذلك، كان هناك بعض الأسباب للتخوّف من أن تبديل المرتبتين إلى أربعة مراتب، أينما وجدت، سيأخذ بالاعتبار بعض الحسابات الحاذقة ضمن شفرة الحاسوب التي أدخلها بعض المبرمجين البارعين لتحقيق اقتصاد أكبر [في خزن البيانات] والسرعة، وفي النهاية، كان هناك قلق حقيقي بأنه بالرغم من إنجاز التعديلات في برامج الحاسوب بشكل صحيح وكامل، إلا أنه قد ينتج منها أخطاء جديدة عند تنفيذها، والفحص المؤكّد للتعديلات المفترضة سيأتي عندما تتغيّر الألفية [فعلاً]، والتي اعتقد معظم الناس، وليس جميعهم، أن ذلك سيحصل في بداية العام 2000، وعلى كل حال، فقد تنامى جزع وسائل الإعلام مع اقتراب كانون الثاني/ يناير 2000، وتنفّس العالم الصعداء عندما أتى [اليوم] ومرّ من دون أثر يذكر في عمليات الأعمال المحوسبة التي أصبح الاقتصاد الدولي معتمداً عليها إلى حدٍّ كبير، ويبدو أن برامج الحاسوب في كل مكان قد أعيد تصميمها [لاحتواء الوضع الجديد].

بدأ النظر لاحقاً إلى مشكلة Y2K بشكل واسع بأنها إنذار زائف، واختفت بسرعة من النقاشات العامة، وما كان العديد يخافون منه كخطأ تصميمي مع تداعيات ذات نسب زلزالية، ثبت أنه جهد كبير حول لا شيء [زوبعة في فنحان] – على الأقل من منظور المراقب العادي، وفي النهاية، فإن مشكلة Y2K التي أدّت إلى قلق كبير في نهاية القرن العشرين ثبت أنها باطلة، من وجهة نظر الأكثرية العظمى للعموم، وتمّ نسيانها بعد وقت قليل. أما مصمِّمو البرمجيات فاحتمال نسيانهم لهذه الحالة أقل، ذلك لأنها تحتوي من جميع معالم حالة دراسية لما يجب ألّا تعمله في برمجة الكومبيوتر أو في أية حالة تصميم أخرى – أي الفشل في تنبؤ تداعيات مستقبلية في قرار يؤخذ اليوم، ولحسن الحظ، فإن خلل مرتبتي التاريخ قد تمّ التعرّف عليه في الوقت الملائم لمعالجته، وللأسف، فليس كل خطأ تصميمي قاتل يمكن اكتشافه قبل أن يُحدث ضرراً. في الواقع، فقبل، وخلال، وبعد التحقّق، والترويج ثم حلّ مشكلة Y2K، تمّ اكتشاف العديد من التصاميم الخاطئة من جميع الأنواع، ولكن في وقت لاحق فقط – بعد فشلٍ أو شبه فشلٍ لا جدال فيه. مثال لذلك كان جسر ميلينيوم (Millennium Bridge) في لندن، الذي اهتزّ كثيراً عندما سُيِّر الناس عليه لأول مرة مما اضطر إلى إغلاقه بعد ثلاثة أيام لإعادة تصميمه.

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

عندما يبتدع المبرمجون ما أُثبت بعد ذلك أنه تطبيق قاصر، إن لم تكن البرامج مُعابة، كانوا يضطرون إلى التصميم ضمن محدّدات ذاكرة متواضعة للأجهزة ووقت حاسوبي مُكلف الثمن. فتقليص السنة إلى نصف مراتبها كان يبدو وكأنّه حدس صائب حينئذٍ. فهو لم يوفر أعداد البيتس والبايتس (Bits and Bytes) للذاكرة الداخلية فحسب، بل اختصر أيضاً الوقت المستغرق والوقت الضائع في عملية طرح غير ضرورية لرقمي "1" و"9"، غير المهمين عندئذٍ، في كل عملية كان فيها زوج من السنين. شمولية مشكلة Y2k بين برامج الحاسوب المكتوبة بلغات الحاسوب القديمة تشير إلى أن المصمِّمين كانوا يفكّرون بشكل مماثل عندما كانوا يواجهون تحدّياً مشتركاً يجب حله ضمن محدِّدات مشتركة. بعبارة أخرى، هم يميلون لإيجاد (أو اكتشاف وتبنّي) حلول مشتركة لأنهم منغمسون جميعاً بما يشار إليه بالحالة السائدة في الفن [التكنولوجيا] (State of the Art). التفكير الجماعي هذا ليس تآمرياً؛ فهو، في الواقع، انعكاس لحقيقة اعتراف، حتى أحسن المصممين، بعدم وجود سبب جيد بالنسبة لهم لرفض خاصة جيدة في التصميم فقط لأنها ليست من ابتكارهم. فباحتضان الحالة الأحدث في فنّ الحل، هم يطلقون عقولهم لمعالجة تحديات أخرى، قد يتوصّلون لبعضها بطرق إبداعية جديدة قد تندمج ضمن حالة متقدمة في فن [الممارسة].

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

فالأختيارات هي بقدر كبير جزء من التصميم، والذي ذهب بعض الكتّاب إلى حدّ أن عرّفوا التصميم كإختيار – أو اتخاذ قرار.