אל תקרא לי מהנדס Not an Engineer

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

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

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

כל השאר, לדעתי, שגוי מן היסוד. 

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

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

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

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

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

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

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

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

בסך הכל - הוובינר היה מעניין למדי, גם אם (ואולי בגלל ש) לא הסכמתי עם כמעט שום דבר ממה שנאמר.


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

The other day, I attended a webinar by Rex Black (is "attended" the correct word for a webinar?). As I think I have already stated - I find his questions very interesting, and most of the time I don't like his answers even a bit. The subject was "Why does software quality (still) suck?". The answer, in short (if we skip the part of "not enough time and budget" which is a general truth) is divided to three parts : 

1. Because software engineering has not yet matured to true engineering.
2. Because we don't know how to measure quality, so we cannot improve in it. 
3. Because software testers are not properly certified. 

I want to start with a short point of agreement - Rex Black has defined this webinar as a rant. That was very correct. 

All of the rest, however, is fundamentally wrong. 

First of all - I do not necessarily agree that the quality of software is low. During most of the webinar, Black uses "defect density" as an indication - until the point where he claims that this isn't a very strong measurement (Since two, very different quality products, can have the same defect density) and says that the main reason of using it is that it is easy to measure and that we don't really have other accurate measurements. Well, I'm a regular user of software. And when I look at the software I use, I can't really say that they are low-quality. Yes, there are bugs, sometimes really annoying ones (at work, my notepad++ is crashing randomly on my work computer. I claim it is still of higher quality than the regular notepad that is stable, to the best of my knowledge), but still, my PC loads reliably, does what I expect it to do and have a pretty decent user experience. Even my five years old phone, that suffers from both wear and weak hardware, is doing its job, more or less. So why insult them with claims of low quality? 

Second - if we claim that we don't know how to measure quality, on what basis is Black claiming that the quality of software sucks? What lies beneath this claim is the fact that even without measurements we can provide some rough, generally acceptable, estimates of software quality. We might not be able to put an exact number to it, but we can T-shirt size it, and if we set up to improve our quality, we can conduct a series of experiments and see if the quality improves. We might miss small improvements, but we will notice bigger improvements, so not being able to measure quality isn't really a reason for poor quality (from this point onward I will accept the claim that software quality sucks for the sake of the argument). 

And now we got to the point that bothered me the most - software development is not yet a true form of engineering. 

This has two part - the correct part, and the wrong part. 

the correct part is that software engineering is very different than other types of engineering that we are familiar with. Other engineering professions are about creating processes and applying (or supervising) them in order to get consistent results in a predictable cost, software engineers are improvising their way forward. 

The wrong part lies in the "yet" part. There are several reasons that lead me to believe that software development (and testing in particular) isn't, and shouldn't be, an engineering field but rather somewhere between a craft and a social science. 

1. 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. 
2. 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. 
3. 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

Now, the third reason mentioned by Black is that software testers aren't properly certified. This claim manages to be at the same time true and twice false. 

It is true in the part that there isn't any common way to join the testing profession or some formal training that is widely accepted. I always feel a bit sad when I hear all those "how I fell into testing" stories (am I the only one who set out of the university and actively looked for a testing position?), but as long as there isn't any clear path a tester should tread, it will probably still be the main way testers find their profession. I think that having some strong certification path can be beneficial both to the testing profession and to the software industry. 

it is wrong once in that that not having a certificate isn't an excuse. Ok, so testers start with a disadvantage. I still expect from an experienced professionals to be good at what they do. A tester with 3 years of experience should be able to provide for the testing needs of a company in a sufficient manner, and a tester with ten years of experience should be able to do testing well and have that added value that might have been easier to achieve with a strong certification.

It is wrong a second time since when Rex Black speaks about certifications, one cannot overlook the certification program that he is involved in - the ISTQB certifications. I'll spare you the usual rant about ISTQB as a certification program (I promise to have a post about it sometime soon), but for now, let's face the bottom line of that rant - The ISTQB certificate (and I refer mostly to the CTFL) isn't providing value, and companies that have a decent percentage of  their testers with CTFL or more advanced certificates are not known for having a better quality products. 

All in all, despite (or maybe because?) I didn't agree with any of the points, it was a very interesting webinar. I strongly recommend listening to Rex Blacks webinars - check up one or two, and see if it makes you think. There's a webinar usually once a month, and the next one is next week.