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

http://www.flickr.com/photos/guitavares/אם המכונית שלנו מתקלקלת אחת לכמה שבועות, אנחנו מחליפים אותה. אך העובדה שמערכות הפעלה ותכנות מורכבות דומות קורסות מדי פעם בפעם הפכה לעובדה שלמדנו לחיות עימה, בלית ברירה. האם נוכל אי פעם להפטר לגמרי מבאגים ושגיאות תוכנה?

 

פרק חדש יצא לאור וניתן להאזין לו באמצעות הנגן שבראש הפוסט, או להוריד אותו למחשב בקישור הזה (מקש ימני, Save As…)

לחץ כאן כדי לקרוא את הפרק במלואו

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

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

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

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

========================================

לחצ/י כאן כדי להרשם לרשימת התפוצה ולקבל עדכונים על פרקים חדשים.

התחברו אל רן בפייסבוק וגוגל+

========================================

פרקים קודמים בנושאים דומים:

פרק 91- רונלד רייגן והמלכה האדומה: על יוזמת 'מלחמת הכוכבים'.
פרק 68- להכריח את בריה"מ להשמיד את ארה"ב: על ההיסטוריה של האינטרנט.
פרק 49- תלת מימד וקופים שאוכלים פסטה- על העתיד של ממשקי מחשב.

========================================

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

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

You may also like...

15 Responses

  1. רן לוי הגיב:

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

    http://www.zdnet.com/blog/projectfailures/new-it-project-failure-metrics-is-standish-wrong/513?tag=content;siu-container

    http://www.it-cortex.com/Stat_Failure_Rate.htm

    ועוד כמה,
    רן

  2. מפקד קוברה הגיב:

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

    מאיפה הסטטיסטיקות של כמה אחוזים מפרויקטי התוכנה נכשלים?

  3. רפי הגיב:

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

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

  4. נעם הגיב:

    אני לא בטוח בקשר להערה של גיא. בעבר ניסו להגיע לשלמות. לפעמים הצליחו. מוצרי צריכה כמו "אמקור 10" עבדו שנים בלי להתקלקל. התכנון היה למוצר שיעבוד. היום מתכננים במתכוון מוצרים שיתכלו. כדי שיתכלו ויוחלפו בחדשים. יתכן וגם לעולם התוכנה זה הגיע. כמו שאמרתי, לא זכור לי שה-VAX בטכניון או ה-IBM קרסו כי משהו הריץ איזה BUG. נכון, המשתמש היה רחוק מהמחשב עצמו, אבל עדיין, הזמינות היתה קרוב ל-100%.
    המצב שבו מעדכנים את מערכת ההפעלה ללא סוף כבר יותר מ-20 שנה. ולא רק גירסאות חדשות אלה תיקונים ותוספות בלי סוף בכל גירסה, זה מצב שלצערי התרגלנו אליו. אם כי יתכן ותוכנה "אידאלית" תעלה יותר מידי, וזה פשוט התשלום עבור המחיר הנמוך
    למערכות בטיחותיות כמו הטסת מטוסים או בקרה על רכבות יש תג מחיר גבוה מאוד ותקנים ובדיקות כדי שהטייס של ה-747 לא יראה מסך כחול מול העיניים.

  5. גיא שולברג הגיב:

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

  6. נעם הגיב:

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

  7. נעם הגיב:

    פרק מעניין.
    אנחנו סובלים מזיכרון סלקטיבי. וזוכרים רק מה שנוח לנו. ההשואה של תוכנה לפרויקט בניה הוא נחמד. זוכרים את "גשר המכביה"? גם הוא תוכנן ונבנה בהצלחה. רק שלא עבד כל כך טוב (to say the least). לא חסרות דוגמאות לפרויקטים מורכבים שלא כל כך צלחו. חיפוש קצר מביא למשל: http://www.youtube.com/watch?v=r1baub0TZj8 או http://www.chinasmack.com/2011/stories/17-million-rmb-luxury-boat-sinks-immediately-after-christening.html
    ויש עוד. בכל תחום שלא ניקח
    לגבי שינוי דרישות במהלך הפרויקט, גם כאן אין הפתעות. זה קורה תמיד ולא רק לתכנתים. סיפור מפורסם הוא "האוניה ואסה" שמופיע ב-WIKI או בתמצית כאן: http://www.haaretz.co.il/misc/1.771106
    תיכנון רכיבי ASIC הוא מורכב לא פחות מתוכנה וגם שם יש תקלות. באמצע שנות ה-90 באחת הגרסאות של ה-386 (SX נדמה לי) היה גם באג במעבד עצמו שגרם לטעויות בביצוע פעולות חשבון של חיבור וחיסור.
    אנחנו גם צריכים להסתכל על תוכנה בכמה רמות. יש את מערכת ההפעלה ויש את האפליקציה. מי שמכיר מחשבים ישנים כמעט ולא נתקל בקריסת המערכת. מחשב IBM340 או VAX היו רצים שנים בלי עדכונים ובלי קריסות ובלי מסכים כחולים (או ירוקים). אני חושב שהם עדיין רצים.
    בפרויקטים מורכבים, וללא ספק בתוכנה מורכבת, יש לבדוק את התקינות. בדרך כלל מדברים על בדיקה שהמערכת עושה את מה שהיא צריכה לעשות. אבל במערכות מורכבות בהם יש המון אפשרויות זה כמעט בלתי אפשרי לעבור על כל האפשרויות. וזה רק על הדברים שהתוכנה כן צריכה לעשות. ומה יקרה עם במסך X נזיז את העכבר לפינה Y ונילחץ על הלחצן הימני?
    כלומר יש (כמעט) אין סוף אפשרויות של פעולות לבדוק לפעולה תקינה ואין סוף גדול יותר של פעולות שלא מוגדרות שגם אותן צריך לבדוק שלא גורמות לתקלות.
    בקיצור, פרויקט מסובך ומורכב הוא מסובך ומורכב. בכל תחום שהוא. אנחנו נוטים לזכור ולהתיחס לתוכנה כי זה קל לנו והמחשב האישי שלנו ככה מתנהג.
    אז אולי הבעיה ב-MICROSOFT שהרגילה אותנו לכך.

  8. שמואל מירילאשוילי הגיב:

    פרק מעולה!

    לגבי החידה –
    התשובה שלי היא, ההבדל באופן ההכנה והמרכיבים.

    לחם באופן מסורתי מיוצר מקמח, מיים ושמרים (או מחמצת שיאור).

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

    להבדיל מבסקוויט או שאר סוגים של עוגיות שלא משתמשים בשמרים.

    מדוע זה קשור לדעתי, התשובה בסוכר שנקר עמילן.

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

    ניסיתי מקווה שהצלחתי!

  9. שלומי הגיב:

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

  10. shlomix הגיב:

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

  11. Oren הגיב:

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

  12. עומרי הגיב:

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

  13. רן לוי הגיב:

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

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

    רן

  14. אפרת הגיב:

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

  15. ניר כץ הגיב:

    פרק מעולה! אני יכול לכתוב פה 10,000 מילים על החוויות שלי בפרויקטים כושלים ומוצלחים שהייתי שותף להם. לתוכנה יש עוד יתרון / חסרון על סוגי הנדסה שונים והזאת המהירות שבה אפשר לעשות דברים, ומהירות היא מהשטן. בשורה התחתונה ניהול נכון, שזאת מיומנות שלדאבוני חסרה מאד בתחום הזה, היא התשובה הכי טובה למשבר התוכנה.
    כדאי גם לזכור שכיום בעידן הענן חברות (כמו גוגל) משחררות במודע גרסאות BETA של המוצרים כדי לראות את התגובה של האנשים ולעשות (TIP (Testing in Production, זה אפשרי כי יש דברים שלא נורא אם הם לא עובדים כל כך טוב (לא כמו מכונית צרפתית).
    דרך אגב העורך עדיין לא נתן אור ירוק לכתבה. אני עדיין לוחץ עליו.

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *