Saturday, March 16, 2019

איכות בארון

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

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

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





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


Quality in the closet


עברית
Quality.
Don't we just love this word? It gives us that warm and fuzzy feeling of doing something well.  But there's something wrong about the way we use it.
I've started thinking about it when I was processing my disagreement with the 5th principle of modern testing and mentioned Jerry Weinberg's definition of quality - value for someone. Then, shortly after, a lot of distractions took over (one very positive such distraction was European Testing Conference) and I put this issue aside for a moment, at least until other things reminded me I had some more to write on this subject.

So, what do I mean by "broken"? Or rather, why do I say it's broken? To answer that I want to go back to school and to the definitions of the trigonometric functions. More specifically, to sine & cosine.
When we were first introduced to the idea of a sine it was through a question: since we know that the relative edge sizes of similar triangles is the same, what can we tell about the size of a right angled triangle's legs related to the hypotenuse? To answer that question we introduced two new mathematical functions - the sine and the cosine. School being school, we went to practice it for a bit, calculating the size of various edges. After getting used to it, the teacher asked a question: What would be the value of a sine for values that are less than zero or more than 90 degrees? The action, at least for the moment, was undefined. Well, what about a new definition? The value of sine(a) for any angle a is the y value of the intersection point between the unit circle and a radius forming an angle of "a" with the X axis. cosine shall be defined to be the x value of that same very point. Great, right? Now we can have this function defined for whichever value we want, and can even deduct some cool properties of those function rather easily (for instance, cosine(x)=cosine(-x)) There's only one thing to do - prove that the new definition does not contradict our previous definition, and it agrees with it at any point where both definitions hold. This proof is rather easy, and the studious readers can complete this exercise by themselves, but this is where I return to the definition of quality in software. Something in the way we define quality is broken. Our definition is inconsistent with the definition of quality in other domains. Moreover, the properties displayed by "quality" examples outside of software are very different than those displayed by software.
Picture an armoire, and not a simple, generic one, a sturdy, dark mahogany armoire, with double doors decorated with fine engravings and polished brass handles. Do you have a picture in mind? Great. Now picture another one, roughly about the same size and shape, made out of plywood, assembled by you with the help of the very detailed Ikea guide, with most screws fitting snugly into their dedicated sockets. Which of the two would you say is of a better quality? Which one are you more likely to see in someone's appartement?
Most people would answer that the mahogany armoire is of better quality, but that the Ikea one is more likely to be used. Why? Because it's cheaper, more accessible, and it doesn't really matter a lot if your child would draw on it with crayons. It might be of lesser quality, but the price is low enough so that we won't mind replacing it every decade or so, and we might even look at it as an opportunity to replace and renew the furniture, which can be nice. Also, if we move to another apartment, as some people do, it will be much easier to leave that armoire behind or resell it instead of going through the fuss of taking it with us. Quality is not the same as "being used a lot", and in fact, the extra cost paid for quality usually makes it used less.
It's not only physical goods that have those properties, if we'll wander to the realms of literature for a moment and compare The Harry Potter series to the Iliad we'll see that the same is true there. Most people would agree that the Iliad is a masterpiece, and that Harry Potter, which sometimes is having difficulties even keeping consistent with itself, is not1. And yet, Harry Potter is being purchased and read far more than the Iliad. Despite the fact the most people would rather spend an evening reading Harry Potter, "quality" is not the reason they do it. In fact, with the exception of software, quality items are less common than their shoddy counterparts. Why would measuring the use of software be any indication of its quality?
We can try to understand the reasons behind this conceptual mistake, and I have my own lousy guesses, but that's not really that important. What is important is to understand that when we use an improper term (or use a term improperly), we mess up all of our gut feelings. It means that we are trying to use quality processes to solve marketing and sales problems, or that we borrow some odd measurements and processes from other fields that mention "quality" (Can anyone explain to me please how on earth did 6-sigma make its way from manufacturing to a presentation about software quality?) This mix also sends us chasing our tail trying to achieve "quality" in places we shouldn't. And, obviously, it causes many people to waste a lot of time and words trying to define "quality" (I considered looking for a link or two for examples, but what have you been reading here up until now?).

As software people, we should stop treating quality as a goal by itself and remember that it is one property that might help us achieve our business goals. When we think about it like that, it is perfectly fine to skip a meticulous definition of this term, since "I'll know it when I see it" is good enough for a single (not that important) property of what makes a project successful. Most importantly, we should embrace the fact that in software too, it is acceptable (and common) to look for Ikea-level quality.



1 I'm not claiming that Harry Potter is bad - it is fun and fluent and has many interesting things in it, it just isn't a masterpiece