top of page

[עושים היסטוריה] 109: באגים, מזוודות וסוכני FBI- על משבר התכנה

16.9.20

[עושים היסטוריה] 109: באגים, מזוודות וסוכני FBI- על משבר התכנה

אם המכונית שלנו מתקלקלת אחת לכמה שבועות, אנחנו מחליפים אותה. אך העובדה שמערכות הפעלה ותכנות מורכבות דומות קורסות מדי פעם בפעם הפכה לעובדה שלמדנו לחיות עימה, בלית ברירה. האם נוכל אי פעם להפטר לגמרי מבאגים ושגיאות תוכנה?

[עושים היסטוריה] 109: באגים, מזוודות וסוכני FBI- על משבר התכנה
00:00 / 01:04
להורדת הפרק
  • Facebook
  • Twitter
  • Instagram
הרשמה לרשימת תפוצה בדוא"ל | אפליקציית עושים היסטוריה (אנדרואיד) | iTunes

באגים, מזוודות וסוכני FBI – על משבר התכנה

כתב: רן לוי

הייתה לי פעם מכונית שכל הזמן התקלקלה. אינני רוצה לנקוב בשמות: אגיד רק שהמכונית הייתה מתוצרת מדינה שתושביה חובבי יין, באגטים ומסתבר שגם מוסכים. בכל חודשיים ביקרתי במוסך, ובכל פעם בגלל תקלה אחרת. לאחר זמן מה הבנתי מדוע אומרים שהחלק הקטן ביותר במכונית צרפתית הוא מוח הבעלים.


מכונית שמתקלקלת אחת לכמה שבועות היא מכונית שרק מזוכיסט יסכים לקנות: אנו מצפים לרמה מסוימת של אמינות מכלי הרכב שלנו . אך שגיאות ותקלות בתכנה, לעומת זאת, הן עניין מוכר ושגרתי עבור כל מי שנעזר במחשבים. כולנו נתקלו במסך השגיאה הכחול של 'חלונות', למשל, ה-Blue Screen of Death המפורסם. גם האייפון והאייפד, מוצרים הידועים כבעלי אכות גבוהה, 'קורסים' מדי פעם וצריך לאתחל אותם. למדנו לחיות עם תקלות תכנה ולקבלן ככמעט מובנות מאליהן. אין מה לעשות.


האם באמת 'אין מה לעשות'? האם תקלות תכנה – מ'באגים' קטנים ועד שגיאות קריטיות – אכן בלתי נמנעות, או שאולי יש תקווה שעם התקדמות הטכנולוגיה נצליח להתגבר על הנגע המרגיז הזה? זו השאלה שבה יעסוק פרק זה.

התוכנות הראשונות

ראשית, כמה מילות הסבר על אופן הפעולה העקרוני של מחשב. מחשב הוא מערכת מורכבת למדי, אבל שני החלקים החשובים והבסיסיים שלו הם המעבד והזיכרון. תאי הזיכרון מכילים מספרים, ותפקידו של המעבד הוא לקרוא מספר מתא זיכרון כלשהו, לבצע עליו פעולה מתמטית או לוגית כגון חיבור או חיסורו להחזירו אל הזיכרון.


תכנה היא רצף הוראות או פקודות המורות למעבד היכן נמצא המידע בזיכרון, ומה עליו לעשות עם המידע. אם נְדָמה את המידע שבזיכרון למוצרי מזון, תכנה היא המתכון המורה לנו מה עלינו לעשות עם המצרכים השונים בכל רגע נתון כדי ליצור עוגה, למשל. שגיאת תכנה- 'באג', בעגה המקצועית- היא טעות ברצף הפקודות: למשל, פקודה חסרה או שתי פקודות בסדר שגוי.


למתכנתי המחשבים הראשונים, בשנות הארבעים והחמישים של המאה העשרים, היה ברור למדי מדוע התכנות שהם כותבים מכילות באגים: כתיבת תכנה הייתה, באותם הימים, משימה סיזיפית, קשה ומורכבת מאוד.


הבה נשים את עצמנו לרגע בנעליו של מתכנת בשנות הארבעים. כיוון שהמעבד מסוגל לקרוא אך ורק מספרים, גם רצף הוראות התכנה חייב להיות מוגדר כסדרת מספרים. כדי לבצע פעולה פשוטה כגון העתקת מספר מתא זיכרון אחד לאחר, למשל, עלינו להזין למחשב סדרת מספרים בסגנון: 11 42 56. כאן "11" ו-"56" הם כתובות תאי הזיכרון, ו"42" היא הפקודה 'העתק'. כדי לבצע חישוב מורכב יותר, כגון פתרון משוואה מתמטית, יש לבצע מאות ואף אלפי פעולות פשוטות שכאלה כגון חיבורים, חיסורים, העתקות וכדומה. נוסף על כך, הסדר, שבו מתבצעות הפעולות האלה קריטי לשם תקינות החישוב כולו, באותו האופן שבו סדר הפעולות הדרושות להכנת עוגה הוא בעל חשיבות רבה: אם נוסיף את הקצפת לפני שהכנסנו את הבצק לתנור, לדוגמה, העוגה כולה תהרס.


המתכנת האומלל נאלץ, אם כן, להפיק סדרות ארוכות של מספרים- 11, 42, 56, 34, 98, 54 ועוד ועוד – אבל אפילו טעות אחת קטנה בסדרה הארוכה תשבש את התוצאה הסופית. אין פלא, אם כן, שבאותה התקופה רק מעט 'משוגעים לדבר' היו מוכנים לעסוק בתִכנות וחלק גדול מזמנם הוקדש לאיתור באגים ותיקונם.


ההתקדמות המשמעותית הראשונה בנושא זה הייתה פיתוחה, בסוף שנות הארבעים, של שפת ה'אסמבלי', המוכרת גם כ'שפת מכונה'. אסמבלי החליפה חלק מהמספרים במילים בעלות משמעות שקל יותר לזכור: לדוגמה, כדי לבצע פעולת חיבור ניתן לכתוב את המילה ADD במקום, נאמר, המספר 67. הפקודות היו מוזנות לתוכנה מיוחדת בשם 'אסמבלר' אשר הייתה ממירה את המילים בחזרה למספרים שהמחשב מסוגל להבין.


תכנות בשפת אסמבלי הקל על המתכנתים ופטר אותם מהצורך לזכור בעל פה מספרים שרירותיים, אבל כמעט ולא סייע להם להימנע משגיאות. חישובים מורכבים עדיין דרשו אלפי שורות קוד, וההקפדה על סדר הפעולות הנכון הייתה מתישה וסיזיפית.

Fortran

אחד מאותם מתכנתים מותשים היה ג'ון בקוס (Backus). בקוס היה מתמטיקאי שעבד בחברת IBM על חישוב מסלולי טילים. בקוס שנא לתכנת באסמבלי: זה היה מסובך מדי ומעיק מדי עבורו, והיו שגיאות רבות מדי לגלות ולנפות.


ב-1953 החליט בקוס לעשות מעשה. הוא כתב מִזכר להנהלה ובו הציע להקים קבוצת פיתוח אשר תפתח שפת תכנות חדשה שתחליף את אסמבלי. הפיתרון שהציע בקוס היה ליצור 'שפה עילית', ובאנגלית- High Level Programming Language. שפה עילית היא שפת תכנות שבה כל פקודה שוות ערך להמוני פקודות אסמבלי. פקודות כמו PRINT X להדפסת תו על המסך, או IF X THEN Y שמבצעת פעולה כלשהי בהתקיים תנאי אחר, מחליפות את עשרות שורות הקוד בשפת אסמבלי שנדרשות כדי לבצע פעולות אלו. דרגה כזו של הפשטה תהפוך את התכנות לקל, פשוט וזריז יותר- ומכאן, בשאיפה, שגם תפחית את מספר השגיאות במידה ניכרת.


זה היה רעיון נפלא- אך בקוס לא המציא כאן משהו חדש. 'שפה עילית', או כפי שכונתה אז 'תכנה אוטומטית', הייתה רעיון שקסם לחוקרים רבים בתחום הצעיר של מדעי המחשב, וכמה שפות עיליות פותחו עוד בסוף שנות הארבעים. אך על אף היתרונות המבטיחים של שפות עיליות, מרבית המתכנתים היו ספקניים מאוד כלפיהן ולא ששו לנטוש את שפת האסמבלי למרות הקשיים המרובים שהציבה. הסיבה לכך הייתה ביצועים.


המעבד, כזכור, מבין רק מספרים. כדי שהמחשב יבין פקודות בשפה עילית יש צורך בתכנה מיוחדת בשם 'מהדר', Compiler, אשר תתרגם את הפקודה בשפה העילית – למשל, Print X- לרצף של פקודות האסמבלי הדרושות בכדי להדפיס את האות X. לרוע המזל, תוצאת התרגום הזו הייתה כמעט תמיד גרועה מאוד: בהשוואה לתכנה שנכתבה באסמבלי על ידי מתכנת אנושי מנוסה, קוד התכנה שהפיקו המהדרים היה לרוב 'מנופח' בפקודות מיותרות שהאטו מאוד את מהירות החישוב. כיוון שהמחשבים בשנות הארבעים והחמישים היו גם ככה אטיים וחלשים – הפגיעה הקשה בביצועים הייתה מחיר שאף אחד לא היה מוכן לשלם, ושפות עיליות נותרו בגדר הבטחה בלתי ממומשת. אתגר כתיבת מהדר לשפה עילית אשר יפיק קוד יעיל כמו תכנה שנכתבה באסמבלי נראה לרבים כמעט בלתי אפשרי: כיצד ניתן לצפות מתכנה שתתחרה באינטואיציית המתכנת האנושי המנוסה ובידע שלו?


בקוס היה מודע לגודל האתגר, אך לא נרתע ממנו. במזכר שכתב הדגיש בפני מנהליו את התועלת הכלכלית שעשויה לצמוח ל-IBM משפה עילית מוצלחת: מורכבות התכנות באסמבלי, כתב בקוס, אחראי לכמעט שלושה רבעים מתקציב הפרוייקטים ב-IBM. הזמן הרב שלוקח למתכנתים לכתוב תכנה ולתקן את הבאגים שמתגלים בה מיתרגם לשכר של חודשים רבים.


טיעוניו של בקוס עשו את העבודה, והוא הצליח לשכנע את מנהליו ב-IBM שהחיסכון הכלכלי הצפוי מצדיק ניסיון לפתח שפה עילית חדשה. הוא קיבל אישור להקים קבוצת מחקר ובשנת 1953 החל לאסוף סביבו קבוצת מהנדסים מוכשרים ונלהבים שחזון השפה העילית הנוחה והקלה לתכנות בער גם בקרבם. חברי הקבוצה עבדו אל תוך הלילה, ובמקרים רבים לנו בבית מלון ליד המשרד כדי שיוכלו לנצל זמן מחשב פנוי גם לפנות בוקר.


עיקר המאמץ התרכז בפיתוח המהדר, התכנה שתתרגם את הפקודות לשפת אסמבלי. בקוס ואנשיו ידעו שהצלחת הפרוייקט שלהם תקום ותיפול על יעילות המהדר: אם המהדר יפיק קוד מנופח ומסורבל שיפגע בביצועי המחשב, אף אחד לא ישתמש בשפה החדשה שפיתחו, נוחה וקלה ככל שתהיה. כדי להקשות על העניינים עוד יותר, המחשב החדש שעבורו פיתחו את השפה העילית, IBM-704, היה חזק ומהיר יותר מכל קודמיו כך שכל פגיעה בביצועים ביחס לקוד אסמבלי ידני תודגש אפילו עוד יותר.


ב-1957 הייתה הגרסה הראשונה של השפה העילית החדשה מוכנה, ובקוס נתן לה את השם FORTRAN, קיצור של Formula Translation. השם הסגיר את הייעוד המתוכנן לשפה: חישובים מתמטיים ומדעיים.


בקוס שלח את המהדר, בצירוף חוברת הסבר מפורטת, אל כמה עשרות קבוצות אחרות ב-IBM ואל לקוחות של החברה שעשו שימוש במחשבי ה-704, כדי שיבדקו את FORTRAN וייחוו עליה את דעתם. כל התגובות, כמעט ללא יוצא מן הכלל, היו נלהבות. המאמץ שהשקיעו חברי הצוות השתלם, והקוד שהפיק המהדר היה מוצלח מאוד: מהירות החישוב של תכנה שנכתבה ב-FORTRAN הייתה בהחלט בת השוואה לתכנה שנכתבה באופן ידני באסמבלי. למעשה, המהדר החדש היה כה מוצלח עד כי נחשב לטוב ביותר מסוגו גם כמעט עשרים שנים מאוחר יותר. המשתמשים התמוגגו מהקלות ומהזריזות שבה ניתן לכתוב תכנות באמצעות FORTRAN.


התגובות החיוביות עודדו מאד את ג'ון בקוס ואנשיו. חברי הצוות היו מרוצים כל כך מההצלחה ובטוחים כל כך שהשפה החדשה שפיתחו תפטור את עולם התכנה מתקלות ומבאגים אחת ולתמיד, עד ששילבו בשפה רק מעט מאוד כלים לאיתור שגיאות וניתוחן: הם האמינו כי לא יהיה בהם צורך!


FORTRAN כבשה את עולם התכנה בסערה. אחד מהבודקים סיפר מאוחר יותר, בראיון עיתונאי, איך נדהם לראות עמית שלו – פיזיקאי במכון מחקר גרעיני – כותב תכנה לחישוב מתמטי מסובך באחר צהריים אחד בלבד. כתיבת אותה התכנה, לו נעשתה בשפת אסמלי, הייתה לוקחת שבועות!


בתוך פחות משנה מיציאת הגרסה הראשונה שלה לאור, כמעט מחצית ממשתמשי ה-704 עשו בה שימוש באופן יום-יומי. השילוב של מהדר מוצלח שהפיק קוד אכותי ו'רזה' עם שפה עילית שהפחיתה את מספר השורות בכל תכנה עד פי עשרים ביחס לקוד זהה בשפת אסמבלי, היה הישועה שלה ציפו אלפי מתכנתים טרוטי עיניים.


ב-1961 החליט מכון התקנים האמריקני להפוך את FORTRAN לשפה תקנית. זו הייתה החלטה ששינתה את מהלך ההיסטוריה, שכן כעת כל אחד יכול לכתוב תכנה ב-FORTRAN ולהיות בטוח שהתכנה שלו תעבוד כהלכה גם על מחשבים מתוצרת חברות אחרות, ולא רק על ה- IBM-704. בתוך שנים ספורות כבשה FORTRAN את השוק, ושפת האסמבלי נעלמה כמעט לחלוטין. התכנות הפך לקל ולמהנה יותר, ומהנדסים וחובבי מחשב רבים למדו לתכנת בכוחות עצמם מתוך ספרי לימוד.


בחמישים השנים שחלפו מאז מהפכת ה-FORTRAN הלך עולם התכנה והשתכלל. שפות עיליות חדשות כגון COBOL, ALGOL, C, ADA ואחרות הוסיפו פיתוחים ורעיונות שהפכו את התכנות לקל אף יותר ומותאם לסוגי חישובים מגוונים יותר, מהנהלת חשבונות ועד אינליגנציה מלאכותית. כיום יש מאות שפות עיליות שניתן לבחור מביניהן, ורבות מהן מאפשרות למתכנת ליצור תכנות שיפעלו על מגוון רחב של מחשבים – ממחשבי PC, דרך מקינטושים של אָפּל וכלה בטלפונים חכמים. שפות מודרניות כמו Python, Ruby ו-Javascript הן כה פשוטות עד שאפילו ילדים בני 13 יכולים ללמוד אותן ללא קושי.


גם שפת FORTRAN, אולי תופתעו לשמוע, עדיין איתנו. היא עברה עדכונים ושינויים רבים במרוצת השנים, אך השפה שנוצרה בתקופה שבה תכנות נעשה באמצעות כרטיסיות מנוקבות, חיה ובועטת גם בעידן האינטרנט. למעשה, FORTRAN היא עדיין השפה המועדפת על מדענים ועל חוקרים רבים לשם חישובים מתמטיים מורכבים. ג'ון בקוס הלך לעולמו בשנת 2007, אבל זכה לראות את השפה העילית שיזם משנה את עולם המחשב לתמיד ובעיקר הופכת את התכנות לכיף, במקום סבל. סוף טוב… הכול טוב.

משבר התוכנה

רגע… רגע אחד!

שפות עיליות הפכו את התכנות לקל יותר, אבל הן גם אפשרו לתכנות עצמן להיות מורכבות יותר ובעלות פונקציונליות רבה יותר. אם בשנות הארבעים מחשבים נדרשו לפתור משוואות מתמטיות, בשנות השישים והשבעים הם כבר היו חלק בלתי נפרד מעולם העסקים והשתמשו בהם לצרכים מגוונים יותר, מחישובי שכר ועד למשחקים. מורכבות התכנות ההולכת וגדלה איזנה את היתרונות שבתכנות בשפות עיליות. שפת FORTRAN אכן חוללה מהפכה בעולם התכנות, אבל שגיאות ותקלות בתכנה לא נעלמו. המסכים הכחולים והודעות השגיאה המעצבנות עדיין מלוות אותנו בתדירות גבוהה, כמו נוריות האזהרה במכונית צרפתית שמנסה לטפס את העליות של הכרמל.


בשנות השישים החלו מהנדסים רבים להבין שיש כאן בעיה עקרונית. על אף כל ההתפתחויות החיוביות בעולם התכנה, נותר קושי בסיסי ומתמשך לכתוב תכנות מורכבות שיהיו נקיות משגיאות. זאת ועוד, היה קשה להשלים פרוייקט תכנה גדול באופן "מוצלח": ב"מוצלח", הכוונה היא לפרוייקט שהתוצר הסופי שלו הוא תכנה תקינה (דהיינו, נטולת באגים), שעונה לדרישות הפרוייקט שלשמו היא נוצרה, ושנכתבת בהתאם ללוח זמנים צפוי, ללא חריגות בתקציב, ושניתן לתחזק ולעדכן אותה באופן שוטף גם לאחר גמר הפרוייקט.


הקושי הזה הטריד מהנדסים רבים בעיקר כיוון שבאופן מסורתי מהנדסים מתגאים בדייקנותם וביכולתם להפיק מוצרים מועילים במגבלות זמן ותקציב. מהנדסי התכנה פזלו לעבר תחומי הנדסה אחרים כמו אדריכלות, למשל, ושאלו את עצמם 'מדוע איננו מסוגלים להיות כמוהם?' מהנדסי בניין ואדריכלים בונים בניינים, גשרים ומבנים אחרים כל הזמן, ומבנים אלה – פרט למקרים נדירים ויוצאי דופן – בטוחים לשימוש, אמינים, ותהליך תכנונם עומד במגבלות לוחות הזמנים והתקציב של הפרוייקט. ניסיונם האישי של מהנדסי התכנה אמר להם, לעומת זאת, שהפרוייקטים שלהם כמעט תמיד יעלו ויארכו יותר ממה שתוכנן – והתוצאה תיוותר קוד שמכיל שגיאות מרגיזות שיתגלו ברגע הכי לא מתאים.


בשנת 1968 התכנסו בגרמניה כמה מהמוחות הגדולים של עולם התכנה במסגרת ועידת נאט"ו, כדי לדון בין היתר בקושי הברור ליצור תכנות מוצלחות. פתרונות לא יצאו מהוועידה הזו, אבל לפחות ניתן שם לבעיה: "משבר התכנה."

כיצד נראה 'משבר התכנה' בפועל? הנה דוגמה.

אסון המזוודות של דנבר

בשנת 1989 החליטה עיריית דנבר, בירתה של מדינת קולורדו שבארצות הברית, ליזום את אחד מהפרוייקטים השאפתניים ביותר בתולדותיה: הקמת שדה תעופה גדול ומודרני, שיצעיד את התיירות והעסקים המקומיים אל המאה העשרים ואחת. היהלום שבכתר שדה התעופה החדש היה אמור להיות מערכת שִינועַ מזוודות הנוסעים.


בכל שדה תעופה, העברת המזוודות מהמטוס הנוחת אל המסוע שבו ממתין הנוסע הוא תהליך בעל חשיבות רבה: אם המזוודה תתעכב יותר מדי בדרך, הנוסע עשוי להפסיד את הטיסה הבאה שלו וכמובן שמזוודה שהלכה לאיבוד בשדה התעופה יכולה להרוס באבחה אחת את מה שהייתה אמורה להיות חופשה מהנה.


החברה שנבחרה לתכנן את מערכת שינוע המזוודות החדשה ולהקימה הייתה BAE, יצרנית ותיקה ומנוסה של מערכות כאלה. מהנדסי BAE בחנו את תכניות שדה התעופה החדש והבינו ששינוע המזוודות עומד להיות אתגר קשה במיוחד. השדה המתוכנן היה ענק והשתרע על פני קילומטרים רבים, כך שהעברת המזוודות מהמטוס אל המסוע בטרמינל בשיטה המסורתית – דהיינו, כלי רכב מאויישים הסוחבים מאחוריהם עגלות מלאות – הייתה יכולה לקחת שלושת רבעי השעה ויותר, פרק זמן לא מתקבל על הדעת בכל קנה מידה.


על כן הציעה BAE להקים בשדה החדש מערכת שינוע מתוחכמת ונועזת במיוחד, מתקדמת בסדרי גודל מכל מה שהיה קיים בראשית שנות התשעים. התכנית הייתה שמערכת השינוע תהיה אוטומטית לחלוטין: מהרגע שהמזוודה עוזבת את בטן המטוס ועד שתגיע אל בעליה, יד אדם לא תיגע בה. סורקי בר-קוד יזהו את יעדה של המזוודה, ומערכת בקרה ממוחשבת תדאג לכך שעגלה ריקה כבר תחכה לה במקום ובזמן המתאימים כדי להסיע אותה במהירות אדירה באמצעות מערכת מסועפת של מסילות תת-קרקעיות, אל הטרמינל הנכון. המתכננים היו בטוחים כל כך ביכולות מערכת הבקרה, עד שהעגלות אפילו לא היו אמורות לעצור; המזוודות אמורות היו ליפול מהמסוע אל עגלת הנוסעים בתזמון מושלם תוך כדי תנועת העגלה.


הקפו המתוכנן של פרוייקט שינוע המזוודות היה עוצר נשימה: 700 אלף קילומטרים של חוטים וכבלים, 40 קילומטרים של מסילות תת-קרקעיות ועשרת אלפים מנועים חשמליים. מערכת הבקרה כללה רשת של כ-300 מחשבים שיפקחו על המנועים והעגלות. אין פלא שראש עיריית דנבר הגדיר את הקמת מערכת שינוע המזוודות כ'פרוייקט בסדר הגודל של כריית תעלת פנמה.'


העיר כולה עקבה אחר התקדמות הפרוייקט, שאמור היה להסתיים בסוף שנת 1993. זמן מה לפני תאריך היעד, הודיע ראש העיר כי פתיחת שדה התעופה תתעכב במעט, כיוון שעדיין נותרו כמה בדיקות קטנות לעשות למערכת המזוודות. אף אחד לא הופתע: בכל זאת, מדובר במערכת חדשנית ומורכבת, וסביר שהבדיקות יתארכו מעט יותר מהצפוי.


אבל איש לא היה מוכן למבוכה שהתרחשה במרץ 1994, כשראש העיר הגאה הזמין את העיתונאים להדגמה חגיגית של המערכת החדשה. במקום שינוע זריז, יעיל ומתוזמן בדייקנות, העיתונאים הנדהמים חזו בגרסה הטכנולוגית של הגהנום של דנטה. עגלות שהגיעו מהר מדי נפלו מהמסילות והתהפכו על הרצפה. מזוודות עפו באוויר כשהעגלות שהיו אמורות להמתין להן ביציאה מהמסועים מעולם לא הגיעו. בגדים שנשפכו מהמזוודות נגרסו בתוך המנועים החשמליים והסתבכו בגלגלי עגלות חולפות. מזוודות שכן הצליחו למצוא אל דרכן אל עגלה ריקה הגיעו אל הטרמינל הלא נכון כשסורקי בר-קוד רבים כשלו בזיהוי המדבקות שעליהן. בקיצור – דבר לא עבד כמו שצריך.


העיתונאים שצפו במחזה לא ידעו אם לצחוק או לבכות. אלמלא עלה הפרוייקט קרוב ל-200 מיליון דולר מכספי משלם המיסים העירוני, זו הייתה יכולה להיות קומדיה הוליוודית קלאסית בסגנון צ'רלי צ'פלין. הכותרות בעיתוני המחרת גרמו לראש העיר להתכווץ בכיסאו, ללא ספק.


מאחורי הקלעים היו שקועים כל המעורבים בפרוייקט בניסיונות נואשים להציל את המצב. טכנאים התרוצצו בין המסילות, אך כל ניסיון לתקן תקלה במקום אחד יצר שתי תקלות חדשות במקום אחר. מורל העובדים המתוסכלים היה על הקרשים. כל יום של עיכוב בפתיחת שדה התעופה בגלל הכשלים שבמערכת המזוודות עלה לעירייה מיליון דולר, והחובות הלכו ותפחו לממדי ענק. לקראת סוף 1994 ניצבה דנבר בפני האפשרות הריאלית מאוד של פשיטת רגל.


לראש עיריית דנבר לא הייתה ברירה. לאחר סדרת מבדקים חיצוניים ודיוני חירום, הוחלט לבטל ולפרק חלק גדול מהמערכת האוטומטית החדשה. במקומה הוקמה בבהילות מערכת מסורתית של שינוע מזוודות ידני, בכלי רכב נהוגים על ידי בני אדם…העלות הסופית של הפרוייקט, כולל עלות הקמתה המזורזת של מערכת השינוע הידנית, הייתה 311 מיליוני דולרים: פי שניים מהעלות המתוכננת.


בפברואר 1995, כמעט שנה וחצי לאחר התארי