Software crisis আর software engineering-এর ইতিহাস — ১৯৬৮-র NATO সম্মেলন থেকে আজ

১ · শুরুর দিন — যখন প্রোগ্রাম লেখা ছিল এক ধরনের কারিগরি

পর্ব ১-এ (Software engineering কী) দেখেছেন, কোড লেখা আর টেকসই software বানানো এক জিনিস নয়। এই পর্বে প্রশ্নটি ইতিহাসের: মানুষ কবে, কোন ব্যথা থেকে এই পার্থক্যটি বুঝল? উত্তর খুঁজতে একটু পেছনে যেতে হবে।

১৯৫০-এর দশকে কম্পিউটার ছিল ঘরভর্তি যন্ত্র, সংখ্যায় খুব কম, আর দামে আকাশছোঁয়া। প্রোগ্রাম লিখতেন অল্প কয়েকজন — প্রায়ই গণিতবিদ বা বিজ্ঞানী, যিনি নিজের সমস্যাটি নিজেই সমাধান করছেন। প্রোগ্রাম ছোট, ব্যবহারকারী একজনই, আর ভুল হলে যিনি লিখেছেন তিনিই ঠিক করে নেন। ১৯৫৭ সালে FORTRAN আর ১৯৫৯ সালে COBOL-এর মতো high-level ভাষা আসার পর কোড লেখা সহজ হলো, কিন্তু “কীভাবে বড় দলে বড় প্রোগ্রাম বানাতে হয়” — এর কোনো লিখিত নিয়ম তখনো ছিল না।

১৯৬০-এর দশকে কম্পিউটার ব্যাংক, বিমান সংস্থা, সামরিক বাহিনী আর মহাকাশ গবেষণায় ঢুকে পড়ল। প্রোগ্রাম হলো লক্ষ লাইনের, লিখতে লাগল শত শত মানুষ, আর ব্যবহার করবেন এমন লোক যাঁরা কোড কখনো দেখবেন না। সবচেয়ে আলোচিত উদাহরণ IBM-এর OS/360 — System/360 কম্পিউটার পরিবারের অপারেটিং সিস্টেম। এর উন্নয়ন দেরিতে চলেছিল, খরচ বেড়েছিল, আর প্রথম দিকের সংস্করণে অনেক ভুল ছিল; এর ব্যবস্থাপনার অভিজ্ঞতা থেকেই পরে Fred Brooks তাঁর বিখ্যাত বইটি লেখেন (অংশ ৪)।

২ · Software crisis আর ১৯৬৮-র NATO সম্মেলন

১৯৬০-এর দশকের শেষ ভাগে প্রকৌশলী ও গবেষকেরা যে অবস্থার কথা বলতেন, তাকেই পরে বলা হলো software crisis. লক্ষণগুলো ছিল পরিচিত, আজও শোনা যায়:

• সময় ও বাজেট ছাড়িয়ে যাওয়া: এক বছরের কাজ তিন বছরে গড়ায়, খরচ বাড়তেই থাকে।
• অনির্ভরযোগ্য system: ব্যবহারকারীর হাতে পৌঁছানোর পর একের পর এক ভুল বের হয়।
• যা চাওয়া হয়েছিল তা নয়: শেষে দেখা যায়, ব্যবহারকারীর আসল প্রয়োজন কেউ ঠিকমতো বোঝেননি।
• রক্ষণাবেক্ষণ প্রায় অসম্ভব: কোড এত জট পাকানো যে একটি জিনিস ঠিক করতে গেলে আরেকটি ভাঙে।

মূল কারণটি সবচেয়ে সুন্দর করে বলেছিলেন Edsger W. Dijkstra, তাঁর ১৯৭২ সালের Turing Award বক্তৃতা “The Humble Programmer”-এ। তাঁর যুক্তির সারকথা: যন্ত্র যখন দুর্বল ছিল, প্রোগ্রামও ছোট ছিল; যন্ত্র যত শক্তিশালী হলো, মানুষ তত বড় ও জটিল প্রোগ্রাম বানাতে চাইল — আর প্রোগ্রাম লেখার পদ্ধতি সেই গতিতে বড় হয়নি। অর্থাৎ সমস্যাটা যন্ত্রের নয়, মানুষের চিন্তা ও কাজের পদ্ধতির।

Garmisch, অক্টোবর ১৯৬৮

এই অবস্থা নিয়ে আলোচনা করতে NATO-র Science Committee ১৯৬৮ সালের অক্টোবরে তখনকার পশ্চিম জার্মানির Garmisch শহরে একটি সম্মেলনের আয়োজন করে। বিভিন্ন দেশের প্রায় পঞ্চাশজন বিশেষজ্ঞ — বিশ্ববিদ্যালয়ের গবেষক, কম্পিউটার কোম্পানির প্রকৌশলী, বড় ব্যবহারকারী প্রতিষ্ঠানের প্রতিনিধি — এক সপ্তাহ ধরে design, উৎপাদন, পরীক্ষা আর রক্ষণাবেক্ষণের সমস্যা নিয়ে কথা বলেন। প্রতিবেদনটি সম্পাদনা করেন Peter Naur ও Brian Randell, প্রকাশিত হয় ১৯৬৯ সালে।

সম্মেলনের নামটিই ছিল বার্তা: “Software Engineering”. প্রতিবেদনের ভূমিকায় বলা হয়েছে, নামটি ইচ্ছে করে উসকানিমূলকভাবে বাছা হয়েছিল — বোঝাতে যে software বানানোকেও প্রতিষ্ঠিত প্রকৌশল শাখাগুলোর মতো তাত্ত্বিক ভিত্তি আর ব্যবহারিক শৃঙ্খলার ওপর দাঁড়াতে হবে। নামটির প্রস্তাবক হিসেবে প্রায়ই জার্মান কম্পিউটার বিজ্ঞানী Friedrich L. Bauer-এর নাম বলা হয়। তবে শব্দটি এর আগেও কিছু লেখায় ব্যবহৃত হয়েছিল; NATO সম্মেলন শব্দটি আবিষ্কার করেনি, জনপ্রিয় করেছে — এভাবে বলাই নিরাপদ।

পরের বছর, ১৯৬৯ সালের অক্টোবরে রোমে দ্বিতীয় সম্মেলন হয় (প্রতিবেদনের সম্পাদক J. N. Buxton ও Brian Randell). Randell-সহ অংশগ্রহণকারীদের পরের লেখা অনুযায়ী দ্বিতীয়টি প্রথমটির মতো সফল হয়নি — তত্ত্বের মানুষ আর বাস্তবের মানুষের মধ্যে আলোচনা মেলেনি। এই টানাপোড়েন আজও আছে: গবেষণাগারের পদ্ধতি আর কারখানার বাস্তবতা সবসময় এক কথা বলে না।

৩ · Dijkstra, goto আর structured programming

NATO সম্মেলনের বছরেই, ১৯৬৮ সালের মার্চে, Communications of the ACM-এ Dijkstra-র একটি ছোট চিঠি ছাপা হয়: “Go To Statement Considered Harmful”. শিরোনামটি দিয়েছিলেন পত্রিকার সম্পাদক Niklaus Wirth; Dijkstra-র নিজের শিরোনাম ছিল আরও শান্ত। চিঠির মূল কথা: goto দিয়ে প্রোগ্রামের যেকোনো জায়গা থেকে যেকোনো জায়গায় লাফ দেওয়া যায়, ফলে কোড পড়ে বোঝা কঠিন হয় — এই মুহূর্তে প্রোগ্রাম কোন অবস্থায় আছে, তা লেখা দেখে আর বলা যায় না।

এর আগেই, ১৯৬৬ সালে Corrado Böhm ও Giuseppe Jacopini দেখিয়েছিলেন যে যেকোনো হিসাব তিনটি মাত্র কাঠামো দিয়ে লেখা যায়: ক্রম (একটির পর একটি), বাছাই (if-else) আর পুনরাবৃত্তি (loop). এই তিনটির ওপর দাঁড়ানো লেখার ধারাকে বলা হয় structured programming. ১৯৭২ সালে Ole-Johan Dahl, Dijkstra ও Tony Hoare-এর Structured Programming বইটি ধারণাটিকে ছড়িয়ে দেয়।

বিতর্কটি এক পক্ষের জয়ে শেষ হয়নি। ১৯৭৪ সালে Donald Knuth “Structured Programming with go to Statements” লিখে দেখান, কিছু জায়গায় (যেমন loop থেকে তাড়াতাড়ি বেরোনো বা error হলে পরিষ্কারের কোডে যাওয়া) নিয়ন্ত্রিত লাফ কোডকে বরং পরিষ্কার করে। আজকের break, return, try/catch সেই নিয়ন্ত্রিত লাফেরই নিরাপদ রূপ, আর C-র Linux kernel-এ এখনো error-পরিষ্কারের জন্য goto দেখা যায়। আসল শিক্ষা “goto নিষিদ্ধ” নয়; শিক্ষা হলো কোড এমনভাবে লিখুন, যাতে পড়ে তার আচরণ বোঝা যায়।

৪ · Brooks — The Mythical Man-Month আর No Silver Bullet

Fred Brooks ১৯৬০-এর দশকে IBM-এ System/360 আর তার অপারেটিং সিস্টেম OS/360-এর উন্নয়ন পরিচালনা করেছিলেন। সেই অভিজ্ঞতা থেকে ১৯৭৫ সালে প্রকাশিত হয় The Mythical Man-Month: Essays on Software Engineering. বইটির নামেই একটি ভ্রান্ত ধারণাকে আক্রমণ করা হয়েছে: “man-month” বা “মানুষ-মাস” — অর্থাৎ ১০ জন × ৬ মাস = ৬০ মানুষ-মাস, তাই ২০ জন দিলে ৩ মাসেই হবে। Brooks দেখান, মানুষ আর মাস এভাবে অদলবদল করা যায় না।

Brooks’s law

বইয়ের সবচেয়ে বিখ্যাত বাক্যটি Brooks’s law: “Adding manpower to a late software project makes it later.” — দেরি হওয়া software project-এ লোক বাড়ালে সেটি আরও দেরি হয়। Brooks তিনটি কারণ দেখান:

1. শেখার সময় (ramp-up): নতুন মানুষ প্রথম কয়েক সপ্তাহ প্রায় কিছুই দিতে পারেন না, উল্টো পুরোনোদের সময় নেন — তাঁদের বোঝাতে হয় কোড কোথায়, নিয়ম কী।
2. যোগাযোগের খরচ: n জনের দলে প্রতি দুজনের মধ্যে একটি যোগাযোগের পথ; মোট পথ n(n−1)/2 — লোক বাড়লে পথ বাড়ে বর্গের হারে।
3. সব কাজ ভাগ করা যায় না: Brooks-এর উদাহরণ — একটি শিশুর জন্ম নিতে নয় মাস লাগে, যত জন মা-ই নিয়োগ করুন না কেন।

নিচের stepper-এ দলের আকার বাড়ানোর সাথে যোগাযোগের পথ কীভাবে বাড়ে, দেখুন। ধরে নেওয়া হলো প্রতিটি পথে সপ্তাহে গড়ে ১ ঘণ্টা সমন্বয় লাগে (সংখ্যাটি শেখার জন্য ধরা)।

এবার একটি খেলনা মডেলে Brooks’s law নিজেই চালিয়ে দেখুন। অনুমানগুলো কোডের প্রথম লাইনগুলোতে স্পষ্ট লেখা — সংখ্যাগুলো বানানো, কিন্তু প্রতিটি অনুমান Brooks-এর তিনটি কারণের একটির প্রতিনিধি। দিনে দিনে কাজের সামান্য ওঠানামা একটি নির্দিষ্ট seed-এর PRNG থেকে আসে, তাই প্রতিবার ফল একই।

// Brooks's law toy model. Assumptions are stated, numbers are made up.
// - 4 people; work turns out to be 200 person-days; 1 unit/day per expert
// - each person loses 0.03 of the day per other team member (communication)
// - a newcomer produces 0 for 20 days, then 0.5 for 20 days, then 1
// - while a newcomer is under 40 days old, one expert spends 0.25 day/day on them
// - day-to-day noise +-5% from a seeded PRNG (same for every run)
function mulberry32(a) { return function () { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
function finishDay(addPeople, addOnDay) {
  const rand = mulberry32(1975);
  let left = 200, day = 0;
  const joined = [0, 0, 0, 0];                       // day each person joined
  while (left > 0) {
    day++;
    if (day === addOnDay) for (let k = 0; k < addPeople; k++) joined.push(day);
    const n = joined.length;
    let work = 0, mentoring = 0;
    for (const j of joined) {
      const age = day - j, base = j === 0 ? 1 : age < 20 ? 0 : age < 40 ? 0.5 : 1;
      if (j > 0 && age < 40) mentoring += 0.25;
      work += base * (1 - 0.03 * (n - 1));
    }
    left -= (work - mentoring) * (0.95 + 0.1 * rand());
  }
  return day;
}
console.log("no one added        : day", finishDay(0, 1));
for (const k of [2, 4, 8]) console.log("add " + k + " on day 30     : day", finishDay(k, 30));
console.log("add 4 on day 1      : day", finishDay(4, 1));

no one added        : day 55
add 2 on day 30     : day 59
add 4 on day 30     : day 63
add 8 on day 30     : day 71
add 4 on day 1      : day 53

Second-system effect আর conceptual integrity

Brooks আরও দুটি ধারণা দিয়েছেন, যা আজও design review-তে শোনা যায়। Second-system effect: একজন নকশাকার প্রথম system-টি সাবধানে, সংযত হয়ে বানান; সফল হলে দ্বিতীয়টিতে প্রথমবার বাদ রাখা সব “সুন্দর ইচ্ছা” ঢুকিয়ে দেন — ফলে দ্বিতীয় system ফুলে-ফেঁপে ভারী হয়ে যায়। Brooks-এর ভাষায় দ্বিতীয়টিই একজন নকশাকারের জীবনের সবচেয়ে বিপজ্জনক system.

Conceptual integrity: Brooks দাবি করেন, system design-এ সবচেয়ে গুরুত্বপূর্ণ বিবেচনা হলো পুরো system-এর পেছনে একটি সুসংগত ধারণা থাকা — যেন একজন মানুষের মাথা থেকে এসেছে। তিনি উদাহরণ দেন ফ্রান্সের Reims ক্যাথেড্রালের, যা বহু প্রজন্ম ধরে বানানো হলেও নকশায় এক। এর জন্য তিনি architecture (কী বানানো হবে, ব্যবহারকারী কী দেখবেন) আর implementation (কীভাবে বানানো হবে) আলাদা করার পরামর্শ দেন — অল্প কয়েকজন architect, অনেক implementer.

No Silver Bullet (১৯৮৬)

১৯৮৬ সালে IFIP সম্মেলনে Brooks পড়েন “No Silver Bullet — Essence and Accidents of Software Engineering” (১৯৮৭ সালে IEEE Computer-এ পুনর্মুদ্রিত)। ইউরোপীয় লোককথায় রুপার গুলিই একমাত্র অস্ত্র যা নেকড়ে-মানবকে মারতে পারে। Brooks-এর দাবি: আগামী এক দশকে এমন কোনো একক প্রযুক্তি বা ব্যবস্থাপনা কৌশল আসবে না, যা একাই উৎপাদনশীলতা, নির্ভরযোগ্যতা বা সরলতায় দশ গুণ উন্নতি দেবে।

যুক্তিটি দাঁড়িয়ে আছে দুই ধরনের জটিলতার পার্থক্যের ওপর:

Brooks-এর হিসাব: high-level ভাষা আর ভালো টুল ইতিমধ্যে accidental জটিলতার বড় অংশ সরিয়ে দিয়েছে; যা বাকি, তার বেশিরভাগই essential. তাই টুল যত ভালোই হোক, দশ গুণ লাফ আর আসবে না। তিনি essential জটিলতার চারটি দিক দেখান — জটিলতা নিজেই, বাইরের জগতের নিয়মের সাথে মানিয়ে চলা (conformity), সারাক্ষণ বদলানো (changeability) আর অদৃশ্যতা (software-এর কোনো ছবি চোখে দেখা যায় না)। আশার পথ হিসেবে বলেন: তৈরি জিনিস কেনা, prototype দিয়ে requirement পরিষ্কার করা, software-কে “বানানো” নয় বরং ধাপে ধাপে “বাড়ানো” (incremental — পর্ব ৪), আর মহান নকশাকার তৈরি করা।

৫ · Therac-25 — যখন software-কে অন্ধ বিশ্বাস করা হলো

এখন থেকে চারটি নথিভুক্ত ব্যর্থতা দেখব। লক্ষ্য কাউকে দোষ দেওয়া নয়, বরং কী ধরনের ভুল কীভাবে ঘটে তা চেনা। বিবরণগুলো সরকারি তদন্ত প্রতিবেদন আর প্রকাশিত গবেষণার ওপর ভিত্তি করে, সরল করে বলা — খুঁটিনাটির জন্য মূল উৎস পড়ুন।

Therac-25 ছিল Atomic Energy of Canada Limited (AECL)-এর তৈরি একটি radiation therapy যন্ত্র। ১৯৮৫ থেকে ১৯৮৭ সালের মধ্যে যুক্তরাষ্ট্র ও কানাডায় অন্তত ছয়টি দুর্ঘটনায় রোগীরা মাত্রাতিরিক্ত বিকিরণ পান; কয়েকজন মারা যান। সবচেয়ে বিখ্যাত বিশ্লেষণটি Nancy Leveson ও Clark Turner-এর, ১৯৯৩ সালে IEEE Computer-এ প্রকাশিত। তাঁদের বিশ্লেষণ অনুযায়ী মূল সমস্যাগুলো:

• Hardware নিরাপত্তা সরিয়ে software-এর ওপর ভরসা: আগের মডেলগুলোতে বিপজ্জনক অবস্থা আটকানোর জন্য যান্ত্রিক interlock ছিল। Therac-25-এ সেই দায়িত্ব মূলত software-কে দেওয়া হয়।
• পুরোনো কোডের পুনর্ব্যবহার: আগের মডেলের কোডের অংশ নেওয়া হয়েছিল; সেখানে লুকানো ভুল হার্ডওয়্যার interlock-এর কারণে কখনো বিপদ ঘটায়নি, তাই “পরীক্ষিত” মনে হয়েছিল।
• Race condition: operator খুব দ্রুত data সম্পাদনা করলে যন্ত্রের একাধিক কাজ ভিন্ন সময়ে ভিন্ন মান পড়ত। আরেকটি ঘটনায় একটি এক-byte counter-এর overflow একটি নিরাপত্তা-যাচাই এড়িয়ে যেতে দিয়েছিল।
• অস্পষ্ট error বার্তা আর অতি-আত্মবিশ্বাস: যন্ত্র দুর্বোধ্য সংক্ষিপ্ত বার্তা দেখাত, operator-রা অভ্যাসবশত এগিয়ে যেতেন; প্রথম দিকের অভিযোগে software-এর সম্ভাবনা গুরুত্ব পায়নি।

নিচের stepper race condition-এর ধারণাটি খুব সরল করে দেখায় — আসল যন্ত্রের কোড বা চিকিৎসা-বিবরণ নয়, শুধু ধরনটি। একটি shared variable mode; একটি কাজ (data entry) সেটি লেখে, আরেকটি কাজ (setup) পড়ে, আর setup শেষ হতে কয়েক সেকেন্ড লাগে। Race condition-এর সাধারণ তত্ত্ব আছে Operating Systems কোর্সের Race condition পর্বে।

৬ · Ariane 5 আর Mars Climate Orbiter — reuse আর এককের ভুল

Ariane 5 Flight 501 (১৯৯৬)

১৯৯৬ সালের ৪ জুন European Space Agency-র নতুন Ariane 5 রকেটের প্রথম উড্ডয়ন। উৎক্ষেপণের প্রায় ৪০ সেকেন্ডের মাথায় রকেট পথ থেকে সরে গিয়ে ভেঙে পড়ে এবং আত্মধ্বংস ব্যবস্থা চালু হয়। Jacques-Louis Lions-এর নেতৃত্বে তদন্ত বোর্ডের প্রতিবেদন (Lions report) কারণটি খুব স্পষ্টভাবে বলে, আর এটি software engineering-এর সবচেয়ে বেশি পড়ানো case study-গুলোর একটি।

রকেটের দিক ও অবস্থান মাপে Inertial Reference System (SRI). এর software নেওয়া হয়েছিল Ariane 4 থেকে — সেখানে বহু বছর ঠিকঠাক চলেছে। কিন্তু Ariane 5-এর উড্ডয়নের ধরন আলাদা: শুরুর দিকে তার horizontal velocity অনেক দ্রুত বাড়ে। একটি অংশে horizontal velocity-সম্পর্কিত একটি মান 64-bit floating-point থেকে 16-bit signed integer-এ রূপান্তর করা হতো। 16-bit signed integer ধরতে পারে শুধু −32768 থেকে 32767; Ariane 5-এ মানটি এই সীমা পেরিয়ে যায়।

এবার ভুলটির ধরন নিজের হাতে তৈরি করুন। নিচের প্রোগ্রামে একটি float মান প্রতি সেকেন্ডে বাড়ছে, আর তিনভাবে সেটিকে 16-bit signed integer-এ রাখা হচ্ছে: (ক) শুধু নিচের 16 bit রেখে দেওয়া — যা অনেক ভাষায় integer রূপান্তরে ঘটে; (খ) Ada-র মতো সীমা ছাড়ালে exception; (গ) একটি range check যা নিরাপদে ব্যর্থ হয় — সীমায় আটকে দেয় আর alarm তোলে। সংখ্যাগুলো শেখার জন্য বানানো, আসল উড্ডয়নের data নয়।

// Ariane 5-class bug. ILLUSTRATIVE numbers only, not flight data.
function mulberry32(a) { return function () { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rand = mulberry32(501);              // fixed seed: same output every run
const MIN16 = -32768, MAX16 = 32767;       // range of a 16-bit signed integer
function wrap16(x) {                       // keep only the low 16 bits
  const b = Math.trunc(x) & 0xFFFF;
  return b > MAX16 ? b - 65536 : b;
}
function strict16(x) {                     // Ada-style: out of range -> exception
  const v = Math.trunc(x);
  if (v < MIN16 || v > MAX16) throw new RangeError("Operand Error " + v);
  return v;
}
function safe16(x) {                       // range check that fails safe
  const v = Math.trunc(x);
  if (v > MAX16) return MAX16 + " (clamped, alarm)";
  if (v < MIN16) return MIN16 + " (clamped, alarm)";
  return String(v);
}
console.log("t  float64    wrap16  strict16   safe16");
for (let t = 0; t <= 6; t++) {
  const x = 20000 + 3000 * t + (rand() - 0.5) * 100;   // grows every second
  let s;
  try { s = String(strict16(x)); } catch (e) { s = "EXCEPTION"; }
  console.log(t + "  " + x.toFixed(1).padStart(8) + "  " + String(wrap16(x)).padStart(7) +
    "  " + s.padEnd(9) + "  " + safe16(x));
}

t  float64    wrap16  strict16   safe16
0   20036.5    20036  20036      20036
1   22968.1    22968  22968      22968
2   26027.2    26027  26027      26027
3   29044.4    29044  29044      29044
4   31999.2    31999  31999      31999
5   35000.8   -30536  EXCEPTION  32767 (clamped, alarm)
6   38042.5   -27494  EXCEPTION  32767 (clamped, alarm)

Mars Climate Orbiter (১৯৯৯)

১৯৯৯ সালের ২৩ সেপ্টেম্বর NASA-র Mars Climate Orbiter মঙ্গলের কক্ষপথে ঢোকার সময় হারিয়ে যায়। NASA-র Mishap Investigation Board-এর প্রতিবেদন অনুযায়ী মূল কারণ: মাটিতে চলা একটি software-এর ফাইল (contractor Lockheed Martin-এর তৈরি) thruster-এর ছোট ছোট জ্বালানির ধাক্কা (impulse) হিসাব করত pound-force·second (lbf·s) এককে, অথচ দুই দলের মধ্যে সই করা interface specification অনুযায়ী মানটি হওয়ার কথা ছিল metric একক newton·second (N·s)-এ। JPL-এর navigation দল সংখ্যাটিকে N·s ধরে ব্যবহার করে। ১ lbf·s ≈ 4.448222 N·s, তাই প্রতিটি ছোট ধাক্কার প্রভাব প্রায় ৪.৪৫ গুণ কম ধরা হলো। মাসের পর মাস এই ছোট ভুল জমে মহাকাশযানের পথ মঙ্গলের অনেক কাছে নিয়ে যায়।

নিচের কোডে প্রথম অংশ ভুলটি পুনরায় তৈরি করে, দ্বিতীয় অংশ একটি ছোট typed-unit wrapper দিয়ে তা ধরে। Thruster-এর ধাক্কাগুলো seed দেওয়া PRNG থেকে বানানো, আসল মিশনের data নয়।

// Mars Climate Orbiter-class bug. ILLUSTRATIVE burns, not mission data.
function mulberry32(a) { return function () { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rand = mulberry32(1999);
const N_S_PER_LBF_S = 4.448222;             // 1 lbf*s = 4.448222 N*s
// Team A: the spec says N*s, but this module really outputs lbf*s (a bare number).
const burns = Array.from({ length: 5 }, () => 0.5 + Math.round(rand() * 10) / 10);
const sentNumber = burns.reduce((a, b) => a + b, 0);
// Team B (navigation) reads the bare number as N*s.
console.log("burns (lbf*s):", burns.join(", "));
console.log("navigation used :", sentNumber.toFixed(3), "N*s");
console.log("real impulse    :", (sentNumber * N_S_PER_LBF_S).toFixed(3), "N*s");
console.log("underestimated by factor", N_S_PER_LBF_S);

// Fix: a tiny typed-unit wrapper. A bare number is rejected.
const TO_N_S = { "N*s": 1, "lbf*s": N_S_PER_LBF_S };
class Impulse {
  constructor(value, unit) {
    if (!(unit in TO_N_S)) throw new TypeError("unknown unit " + unit);
    this.value = value; this.unit = unit;
  }
  inNs() { return this.value * TO_N_S[this.unit]; }
}
function navUpdate(imp) {
  if (!(imp instanceof Impulse)) throw new TypeError("navUpdate needs an Impulse with a unit");
  return imp.inNs();
}
try { navUpdate(sentNumber); } catch (e) { console.log("caught:", e.message); }
console.log("typed  :", navUpdate(new Impulse(sentNumber, "lbf*s")).toFixed(3), "N*s");

burns (lbf*s): 0.9, 0.7, 1.4, 0.9, 0.6
navigation used : 4.500 N*s
real impulse    : 20.017 N*s
underestimated by factor 4.448222
caught: navUpdate needs an Impulse with a unit
typed  : 20.017 N*s

৭ · Knight Capital, ব্যর্থতার শিক্ষা আর CHAOS বিতর্ক

Knight Capital (২০১২)

২০১২ সালের ১ আগস্ট যুক্তরাষ্ট্রের শেয়ারবাজারের বড় একটি ট্রেডিং প্রতিষ্ঠান Knight Capital নতুন একটি বাজার-কর্মসূচির জন্য তাদের order-routing software হালনাগাদ করে। যুক্তরাষ্ট্রের Securities and Exchange Commission (SEC)-এর ২০১৩ সালের নথি অনুযায়ী ঘটনাটি এমন:

• নতুন কোড আটটি server-এ হাতে হাতে বসানোর কথা ছিল; একজন প্রকৌশলী একটিতে বসাতে ভুলে যান, আর কেউ দ্বিতীয়বার যাচাই করেননি।
• নতুন কোড একটি পুরোনো flag-কে নতুন অর্থে ব্যবহার করছিল। ওই flag আগে “Power Peg” নামের বহু বছর ধরে অব্যবহৃত একটি পুরোনো ফাংশন চালু করত — যার কোড তখনো server-এ রয়ে গিয়েছিল (dead code).
• বাজার খোলার পর বাদ পড়া ওই একটি server নতুন বার্তার flag দেখে পুরোনো পথটি চালাল এবং অনিয়ন্ত্রিতভাবে order পাঠাতে লাগল। প্রায় ৪৫ মিনিটে প্রতিষ্ঠানটির ৪৬০ মিলিয়ন ডলারের বেশি ক্ষতি হয় (SEC-এর হিসাব)।
• SEC আরও উল্লেখ করে, deployment যাচাইয়ের লিখিত পদ্ধতি আর এমন ঘটনায় কী করতে হবে তার স্পষ্ট নির্দেশনা ছিল না।

শিক্ষাগুলো সরাসরি আধুনিক delivery-র ভিত্তি: deployment হাতে নয়, স্বয়ংক্রিয় ও পুনরাবৃত্তিযোগ্য pipeline-এ; প্রতিটি server-এ কী version চলছে তা যাচাই; পুরোনো feature flag নতুন অর্থে পুনর্ব্যবহার নয়; অব্যবহৃত কোড মুছে ফেলা; আর দ্রুত বন্ধ করার “kill switch”. Feature flag আর trunk-based development-এর কথা পর্ব ১৭-এ, deployment pipeline পর্ব ৫৯-এ, আর release-এর কৌশল (canary, rollback) System Design কোর্সের Deployment আর release পর্বে।

চার ঘটনা, চার শিক্ষা

সংখ্যা দিয়ে ব্যর্থতা মাপা — CHAOS report বিতর্ক

Software project কত শতাংশ ব্যর্থ হয় — এই প্রশ্নে সবচেয়ে বেশি উদ্ধৃত উৎস Standish Group-এর CHAOS report, প্রথমটি ১৯৯৪ সালে। বহু বই আর বক্তৃতায় এর নাটকীয় শতাংশ “সত্য” হিসেবে ব্যবহার হয়েছে। কিন্তু গবেষকেরা এর পদ্ধতি নিয়ে গুরুতর প্রশ্ন তুলেছেন: Robert Glass (Communications of the ACM, ২০০৬) জিজ্ঞেস করেছেন এটি আসলেই “crisis” প্রমাণ করে কি না; Magne Jørgensen ও Kjetil Moløkken-Østvold (২০০৬) ১৯৯৪-এর রিপোর্টের খরচ-বৃদ্ধির হিসাবকে অন্য গবেষণার সাথে অসংগত পেয়েছেন; আর J. Laurenz Eveleens ও Chris Verhoef (IEEE Software, ২০১০) দেখিয়েছেন যে “ব্যর্থতা”-র সংজ্ঞা — প্রথম অনুমানের সাথে তুলনা — সংখ্যাগুলোকে এক দিকে হেলিয়ে দেয়। সমালোচনাগুলোর মূল কথা: কোন project নমুনায় এল, “ব্যর্থ” কাকে বলা হলো আর raw data প্রকাশ হয়নি কেন।

৮ · Structured থেকে AI — যুগের পর যুগ

১৯৬৮-র পর software engineering এক জায়গায় দাঁড়িয়ে থাকেনি। প্রতিটি নতুন যুগ আগের যুগের কোনো একটি ব্যথার উত্তর হিসেবে এসেছে — আর প্রায়ই নিজের নতুন ব্যথা নিয়ে এসেছে। নিচের ছবিতে দশক ধরে মূল ধারাগুলো:

এবার প্রতিটি মোড় ধাপে ধাপে দেখুন — কোন ব্যথা থেকে কোন উত্তর এল।

৯ · AI-এর যুগে — ইতিহাসের শিক্ষা মনে রেখে AI ব্যবহার

আজকের AI code assistant যেন Brooks-এর প্রশ্নের নতুন পরীক্ষা: এটি কি রুপার গুলি? অভিজ্ঞতা বলছে, AI accidental কাজ — boilerplate, পরিচিত pattern, প্রথম খসড়া test — অনেক দ্রুত করে। কিন্তু এই পর্বের চারটি ব্যর্থতার একটিও “কোড টাইপ করতে দেরি”-র কারণে ঘটেনি। ঘটেছে অনুমান, interface, deployment আর বিশ্বাসের ভুলে — ঠিক যেখানে AI সবচেয়ে আত্মবিশ্বাসী ভুল করতে পারে।

AI সাধারণত যেসব ভুল করে — software engineering-এ

AI-এর লেখা কোড বা পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কোডটি কোন অনুমানে দাঁড়িয়ে (মানের সীমা, একক, সময়, কে কখন ডাকবে) — তালিকা করেছি, আর আমার প্রেক্ষাপটে সেগুলো সত্য কি না যাচাই করেছি
• সীমার মান (সবচেয়ে বড়, সবচেয়ে ছোট, শূন্য, ঋণাত্মক) দিয়ে নিজে চালিয়েছি — শুধু সহজ ইনপুটে নয়
• Git বা deployment-এর যেকোনো ধ্বংসাত্মক command আগে একটি ফেলে-দেওয়া clone-এ চালিয়েছি
• কোনো ইতিহাস, standard বা পরিসংখ্যান থাকলে মূল উৎসে মিলিয়েছি
• diff লাইন ধরে পড়েছি, test চালিয়েছি, আর ইচ্ছে করে একটি ভুল ঢুকিয়ে দেখেছি test সেটি ধরে কি না
• License আর গোপন তথ্য (key, password, গ্রাহকের data) — দুটোই পরীক্ষা করেছি