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

-על 'משבר התוכנה' שממרר את חייהם של המהנדסים עוד משנות השישים…
-על FORTRAN, השפה העילית הראשונה (PDF!) והמהפכה שחוללה בעולם התכנה..
-ועל שני פרוייקטי תכנה שכשלו באופן קטסטרופלי:  מערכת שינוע המזוודות (PDF!) של שדה התעופה בדנוור, ו'תיק החקירה הוירטואלי' (VCF) של סוכנות ה-FBI.

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

חולצות 'עושים היסטוריה' חוזרות, לפחות באופן חד-פעמי. משה וולפסון, מאזין של התכנית, החליט להרים את הכפפה וליזום הדפסה של חולצות התכנית! זו יוזמה ברוכה, שכן לי אין את הזמן לעסוק בנושא. את החולצה החדשה עיצב רועי משעלי הסופר-מוכשר (ראו הגרפיקה בהמשך הפוסט), ומשה לקח על עצמו לאסוף את הזמנותיכם ולארגן את ההדפסה בהתנדבות: כל החולצות יימכרו במחיר עלות בלבד, ללא כל רווח למשה או לי. על פי המסתמן, עלות כל חולצה תהיה כ-17 ש"ח, מחיר זול עד מאד (ואני יודע, עסקתי בעניין לא מעט…). אם אתם מעוניינים להזמין חולצה, אנא צרו קשר עם משה ישירות בכתובת: moishie.w@gmail.com, או בשרשור החולצות בפורום שלנו.

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

---

באגים, מזוודות וסוכני 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, כמעט שנה וחצי לאחר התאריך המקורי, נפתח שדה התעופה החדש של דנבר. רק חברת תעופה אחת, יונייטד-ארליינס, הסכימה להמשיך ולהשתמש במערכת שינוע המזוודות החדשה- אבל גם היא נשברה לבסוף: לכל אורך חייה של המערכת נתגלו בה תקלות רבות ועלות התחזוקה הייתה קרוב למיליון דולר בכל חודש. בשנת 2005 הודיעה כם יונייטד-ארליינס על פירוק המערכת האוטומטית והחלפתה בשינוע מזוודות ידני.

מה השתבש בדנבר? מדוע כשל הפרוייקט באופן כה מביש ומוחלט?

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

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

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

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

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

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

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

אסון התיקים של ה-FBI

מה אפשר לעשות? כיצד ניתן למזער את הסיכון?

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

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

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

בסוף שנת 2000 אישר הקונגרס השקעה של כ-400 מיליוני דולרים בשדרוג מערכת המחשבים של ה-FBI. הפרוייקט תוכנן להימשך כשלוש שנים, ובסיומו תוחלפנה כל עמדות המחשב במחשבים מתקדמים ומודרניים ותותקן רשת תקשורת מהירה באמצעות סיבים אופטיים. גולת הכותרת של המערכת החדשה הייתה תכנה בשם VCF, ראשי תיבות של Virtual Case File (תיק חקירה וירטואלי). VCF הייתה אמורה לאפשר לסוכנים בשטח להעלות מסמכים, תמונות, קבצי שמע וכל חומר חקירה אחר למאגר מידע מרכזי, ולאפשר להם להצליב מידע על חשודים כדי להשיג ראיות מכריעות עבור בית המשפט. החברה שנשכרה כדי לפתח את תוכנת ה-VCF הייתה חברת SAIC.

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

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

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

בדצמבר 2003, כמעט שנה לאחר התאריך המקורי, הוגשה התכנה החדשה לידי הלקוח. ה-FBI דחה אותה כמעט מייד. לא רק שהיו כמה עשרות תקלות ובאגים קריטיים בתכנת ה-VCF, אלא שהיו חסרות בה פונקציות בסיסיות כמו Bookmarking והיסטוריה של חיפוש. תכנת ה-VCF הכילה 700 אלף שורות של קוד מנופח, מלא בטעויות ולא תואם לצרכי השטח.

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

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

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

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

להתמודד עם משבר התוכנה

האם ניתן לצפות ששילוב תהליכי פיתוח תכנה מודרניים ושפות תכנות עיליות ומתוחכמות יותר יביא אותנו, ביום מן הימים, אל הארץ המובטחת? האם ייפתר משבר התכנה, ונוכל לצפות מהתכנות שלנו לאותה רמת אמינות שאנו מצפים מהמכוניות שלנו?

ד"ר פרדריק ברוקס הוא אחד ממדעני המחשב החשובים ביותר במאה העשרים. בעברו ניהל ברוקס במשך שנים רבות כמה מהפרוייקטים החדשניים ביותר של חברת IBM, והניסיון שצבר בניהול פרוייקטים אלה – ובמיוחד כמה מהכישלונות הכואבים שחווה על בשרו – הביאו אותו לכתוב בשנת 1975 ספר בשם The Mythical Man-Month שהשפיע על דור שלם של מהנדסי תכנה ומנהלים. שמו של הספר, 'חודש-האדם המיתולוגי', בתרגום חופשי- מתייחס ליחידת העבודה הסטנדרטית של פרוייקט תכנה: חודש-אדם, או עבודה שעושה מתכנת יחיד במשך חודש שלם.

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

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

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

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

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

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

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

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

מה בכל זאת ניתן לעשות? התשובה, לדידו של ברוקס, ברורה: אל תכתבו תכנה – קנו אותה…

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

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

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

---

יצירות אשר הושמעו במסגרת הפרק:

Windows Error Remix- oOluxux
jlbrock44_-_Blue_Like_Venus
Living In a Dream- Ami Oz

מקורות ומידע נוסף:

http://www.zdnet.com/blog/projectfailures/new-it-project-failure-metrics-is-standish-wrong/513?tag=content;siu-container
http://en.wikipedia.org/wiki/Virtual_Case_File
http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html
http://media.wiley.com/product_data/excerpt/94/08186760/0818676094.pdf
http://spectrum.ieee.org/computing/software/who-killed-the-virtual-case-file/0
http://en.wikipedia.org/wiki/Virtual_Case_File
http://archives.neohapsis.com/archives/isn/2002-q4/0090.html
http://www.washingtonpost.com/wp-dyn/content/article/2006/08/17/AR2006081701485_2.html
http://calleam.com/WTPF/wp-content/uploads/articles/DIABaggage.pdf
http://en.wikipedia.org/wiki/Denver_International_Airport#Automated_baggage_system
http://globalprojectstrategy.com/lessons/case.php?id=23
http://lessons-from-history.com/node/89
https://www.google.com/search?q=denver+airport+lauguge+system#hl=en&sclient=psy-ab&q=tech+project+failures+cases&oq=tech+project+failures+cases&aq=f&aqi=&aql=&gs_l=serp.3…25765l26944l4l27079l6l6l0l0l0l0l132l738l0j6l6l0.llsin.&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&fp=adcb350d65902750&biw=1920&bih=955
http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar
http://agilesoftwarequalities.blogspot.com/2009/08/engineering-practice-and-bridge-design.html
http://users.csc.calpoly.edu/~dstearns/SchlohProject/summary.html
http://www.eis.mdx.ac.uk/research/SFC/Reports/TR2002-01.pdf
http://www.softwarepreservation.org/projects/FORTRAN/paper/p25-backus.pdf
http://books.google.co.il/books?id=j7iTIoJyNk0C&pg=PT80&dq=fortran+backus&hl=en&sa=X&ei=Xl9sT5mnCOfH0QXT4KHLBg&redir_esc=y#v=onepage&q&f=false
http://books.google.co.il/books?id=CEtclF-JMzAC&lpg=PA238&dq=fortran%20backus&pg=PA242#v=onepage&q&f=false