- כי אנחנו לא יודעים למדוד איכות, ולכן לא יודעים להשתפר בה.
- כי תכנות עדיין אינה מקצוע הנדסי כמו שצריך.
- כי בודקי תוכנה (במאמר מוסגר – שאחראים על איכות) אינם מוסמכים כראוי.
טוב, מניין להתחיל?
אני חושב להתחיל עם נקודה של הסכמה – בלאק הגדיר את הוובינר הזה כשחרור קיטור. ההגדרה הזו הולמת למדי, כי זה עיקר מה שהיה בוובינר.
שנית, אם אנחנו לא יודעים למדוד איכות תוכנה – על בסיס מה מוטחת ההאשמה באיכות נמוכה? כלומר, מה שבלאק בעצם אומר הוא שאנחנו יודעים לזהות מקרים של איכות נמוכה או גבוהה. אולי לא נדע להצמיד לזה מספר מדוייק, אבל אנחנו מסוגלים להעריך את המצב באופן מילולי ולומר “התוכנה הזו איכותית הרבה יותר מהתוכנה ההיא, לשתי אלה כאן יש פחות או יותר את אותה רמת איכות”. ואם כך, חוסר היכולת למדוד באופן מדוייק אולי מקשה על שיפור, אבללא חוסם אותו. חברה יכולה בהחלט לערוך סדרה של ניסויים ולאחר כל ניסוי לשאול “האם אנחנו שמים לב לשיפור באיכות?”. כן, אנחנו עשויים לפספס שיפורים קטנים ולא מורגשים (שיכולים להצטבר), אבל אנחנו בהחלט יכולים להשתפר.
- מקצוע הנדסי פועל בסביבה יציבה – מהנדסי בניין, מהנדסי מזון, מהנדסי תעופה או מהנדסי רכב – כל אלה פועלים בסביבה קבועה שאינה משתנה, או שמשתנה לאט מאוד. הכביש בו נסעה המכונית אתמול הוא אותו הכביש בו היא תיסע מחר,ובעוד חודש ובעוד עשרים שנה. הקיבה האנושית תעכל את אותו המזון היום, מחר ובשלושת הדורות הקרובים לפחות. גם האוויר בו טסים המטוסים לא יהפוך חומצי מספיק כדי לאכל מתכת ביום אחד. עולם התוכנה, מצד שני, משתנה בכל יום – טלאי אבטחה של מערכת ההפעלה עלול לחסום שימוש בספרייה חיצונית במוצר אותו אני מפתח, עדכון דפדפן יכול לגרום לאתר שלי להיראות מכוער, ואם מתמטיקאי כזה או אחר ימצא חולשה במגנון ההצפנה שלי, הוא הופך להיות לא בטוח בתוך רגעים מפרסום המאמר. הסביבה הדינמית בה תוכנה קיימת מונעת את היציבות הנדרשת ממקצוע הנדסי.
- תוכנה היא מערכת חוקים שנועדה לפעול בסביבה אנושית. חלק מהבאגים הם עניין של העדפה – גוגל חשבו ששליחת תמונה של המיניונים זה רעיון מגניב, וחלק ממשתמשי הדוא”ל הסכימו איתם. חלק אחר, לא. יש כאן עניין של איזון בין רצונות שונים, וזה כבר עניין של טעם, או של מחקרים סוציולוגיים. מדע מדוייק – זה לא, וזה גם לא יכול להיות. לפחות לא כל עוד אנשים מעורבים בעניין.
- מהנדסים עושים את אותו דבר שוב ושוב ושוב. הבעיות שצריך לפתור בבניית גשר הן קבועות – הוא צריך להיות יפה, זול, עמיד בפני העומס הדרוש, או בפני רעידות אדמה ורוחות כפי שנפוץ שיהיה, וזהו. תוכנה היא עניין חד פעמי – מעט מאוד תוכנות עושות את אותו הדבר בדיוק, ופיתוחים חדשים בתוך אותו מוצר יתמודדו עם בעיות שונות. אני
לא מנסה לומר שהנדסה היא קלה יותר, אלא רק שהיא מובנה ומתוחמת יותר.
היא נכונה, כי אני חושב שהסמכה טובה שתהיה סטנדרט כניסה למקצוע הבדיקות יכולה לתרום המון לתחום בפרט ולתעשיית התוכנה בכלל. לאיש מקצוע יש ערך בהכרה של התיאוריה הרלוונטית לתחום שלו, גם אם אינו משתמש בה באופן ישיר, ואחת הדרכים הטובות ביותר שאני מכיר כדי להשתפר ולרכוש הרגלים טובים היא לתרגל כישורים בסביבה מבוקרת. בנוסף, אם יש חסם כניסה למקצוע, הרבה יותר קל לאנשים מחוץ לתחום לראות את הכישורים הנדרשים, או לפחות להכיר בקיומם, מה שעשוי לעזור להילחם בגישה לפיה “כל אחד יכול לבדוק”.
היא שגויה פעם אחת כי היעדר הסמכה זה לא תירוץ. כי אנשי מקצוע צוברים ניסיון, ידע ומיומנות. אז גם אם נקודת הפתיחה מוצלחת פחות, בודק תוכנה עם שלוש שנות ניסיון אמור להיות מסוגל לתת מענה ראוי לצרכי הבדיקות של מקום העבודה שלו, ובודק תוכנה עם עשר שנות ניסיון אמור להיות מסוגל לתת מענה טוב לצרכים האלה. האם הוא היה עושה עבודה טובה יותר לו היה מוסמך כראוי? יכול להיות. אבל גם אם נקבל את ההנחה לפיה בודקי תוכנה אחראים לאיכות התוכנה, זה עדיין לא מסביר מדוע בודקי תוכנה מנוסים לא מסוגלים להוציא תוכנה באיכות מספקת (שוב, אם אנחנו מקבלים את הטענה הזו).
היא שגוייה פעם שנייה כי רקס בלאק לא מדבר על הסמכה תיאורטית שאף אחד עדיין לא ראה. היא שגוייה כי כשרקס בלאק מדבר על הסמכות, אי אפשר שלא להסתכל על מסלול ההסמכות בו הוא מעורב – זה של ISTQB. נשים רגע בצד את הקיטור הסטנדרטי ונקבל זאת כעובדה (אני מבטיח לפרסם על כך משהו בעתיד הקרוב): ההסמכה הזו אינה מקדמת במילימטר את מקצועיות הבודקים.
בסך הכל – הוובינר היה מעניין למדי, גם אם (ואולי בגלל ש) לא הסכמתי עם כמעט שום דבר ממה שנאמר.
נ.ב.
כשעברתי שוב על הוובינר, נתקלתי בסיבה נוספת שבלאק מציין – כי העלות של תיקוני באגים מושתת על הלקוחות (כתשלום על תמיכה).
אני לא מכיר את השוק מספיק טוב כדי לחוות דעה מוסמכת בנידון, אבל תחושת הבטן שלי היא שיש כאן מתיחה מסויימת של המציאות: חברות שפועלות במודל SaaS לא גובות תשלום על “תמיכה” אלא דמי-שימוש, ובמרבית המקרים בהם אני נתקלתי, המשמעות של “תמיכה” הייתה קבלה של עדכונים ופיצ’רים חדשים, או סיוע בביצוע משימות לא טריוויאליות. אז נכון, חלק מהעדכונים הם תיקוני באגים, אבל טרם שמעתי על חברת תוכנה שיש לה יותר זמן מאשר משימות, וכל באג שמתוקן הוא פיצ’ר שלא יוצא ללקוחות ולקוחות שאינם מצטרפים כי הפיצ’ר הזה חסר.
————————————————————-
- Because software engineering has not yet matured to true engineering.
- Because we don’t know how to measure quality, so we cannot improve in it.
- Because software testers are not properly certified.
istent results in a predictable cost, software engineers are improvising their way forward.
- An engineering profession is operating in a rather stable environment. This environment might be extremely hostile, but is is largely constant – the type of problems do not change drastically or rapidly. Car engineers, avionics engineers or architects are dealing with the same problem again and again – the physics that enable an airplane to fly are constant, the road conditions for cars are pretty much the same as they were in the last 50 years. The solutions might vary, but something that worked in the past, will still work today, and is still a valid measure to compare against.
The software world, however, is changing rapidly. If the first computers were standalone devices, the proliferation of the internet has changed everything, then mobile came and flipped it all upside down, and now we have IoT to change it all again. Moreover – even if we remain in the same world – an OS update might change some of the assumptions that were made when the software was developed (such as – running with admin privileges does not require special approval), or a browser update can make my site look horrible. Even if nothing changed on my computer – it is sufficient that a cryptographer finds a new flaw in an encryption algorithm to suddenly render my software insecure. In such instability, I don’t think it’s feasible to create an engineering practice. - A software is a set of rules that operates in a human environment. Some bugs are simply a matter of preference. Google thought that sending a cute Minions animated .gif is a great idea for April 1st, and some of the users agreed. Some others, however, didn’t. It is a problem of balancing different wills and needs of different people, which is really a matter of taste, or of some psychological \ sociological researches. It is not, and cannot be, an exact science, at least as long as people are involved.
- Engineers solve the same problems over and over. A bridge should carry such and such weight, withstand earthquakes and winds in a given range, be as pretty and cheap possible. Once a solution that satisfies those conditions is found, it can be reused and adjusted over and over. In a software project – each time the software solves a different problem. Even when working on the same project, each new feature is addressing a different problem – the common parts are quickly extracted to libraries. The equivalent of “build a bridge” is something like “open an HTTPS connection” – but software is the whole ecosystem – it’s about the parts that cannot be reused but have to be invented. The engineering equivalent of just about every software isn’t the final model, but rather it is the first prototype.
for theses reasons (and probably some others I just forgot to mention), I don’t think software development should ever be similar to engineering professions
Recent Comments