Monday, April 1, 2019

סופה של תקופה



English Version (TBD)
היום הוא היום האחרון שלי בRSA. 
אחרי שבע שנים וקצת, בעקבות הזדמנות שפחות או יותר קפצה לי לידיים, החלטתי לעזוב את מקום העבודה ולהמשיך הלאה, ומה אגיד לכם? לא קל לעזוב מקום אחרי תקופה כזו ארוכה, בטח לא את מקום העבודה הראשון בו התפתחה כמעט כל האישיות המקצועית שלי עד כה.בכל אופן, סיכומי תקופה כאלה הם הזדמנות לא רעה להסתכל לאחור ולחשוב קצת אז הנה אני, חושב קצת.
הדבר הכי קל הוא להטביע את הכל במספרים, אז אני חושב שאתחיל בזה - 
  • שבע שנים
  • ארבעים ואחד חברי צוות
  • שמונה מנהלים (שניים היום חביר צוות מן המניין קודם)
  • שלושה אנשים שהיו בעבודה לפני ועדיין נמצאים שם
  • ארבע חתונות בצוות ולפחות שמונה לידות
  • מוצר אחד
  • בערך 25 גרסאות "גדולות" ואינספור תיקונים קטנים
  • 10 כנסים בהם השתתפתי , בארבעה מתוכם הרציתי
  • שתי תעודות הסמכה, אחת מהן מיותרת לחלוטין
אבל כמובן, המספרים לא באמת מספרים שום דבר משמעותי, ובטח לא מייצגים את השינויים שחלו בגישה המקצועית שלי ובתפקידים שלי בתוך הצוות. 
מבחינה רשמית, התפקיד שלי בתוך הצוות לא באמת השתנה - גוייסתי כבודק תוכנה מתחיל, ופעמיים במהלך העבודה סיפרו לי שהחליפו לי את הקידומת ל"Senior" ואז ל"Principal", אבל הדברים האלה קרו בלי להוסיף ציפיות רשמיות למה שכבר עשיתי. בפועל, לעומת זאת, השינוי היה דרמטי מאוד. 
התקבלתי לעבודה היישר מהאוניברסיטה, בעקבות הפנייה של חברה, וכיוון שכל מה שידעתי על בדיקות תוכנה היה קורס של סמסטר אחד, חשבתי שתפקידו של בודק תוכנה הוא, ובכן, לבדוק תוכנה (ספויילר - זה לא). הגעתי עם יכולות תכנות סבירות מינוס, ועם ידע בבדיקות שהוא רק קצת יותר מקיף מזה של מי שעבר את בחינת ISTQB CTFL (הקורס באוניברסיטה הועבר ע"י אחד מחברי ITCB, שהוסיף עוד נושא או שניים כדי למלא סמסטר). זה אומר שהגעתי עם כל הכוונות לכתוב הררי ניירת, ולנתח לעומק את התוכנה עליה אני עובד. ובאמת, החווייה הראשונה שלי הייתה  קרובה מאוד לציפיות - רצה הגורל והגעתי בדיוק לתחילתם של שישה סבבי רגרסיה מלאה על המוצר. בדיוק החלפנו מערכת הפעלה, ואז שדרגנו כמה רכיבים מרכזיים בהפתעה, ובכל פעם היה צורך לעבור על כל המערכת מחדש. עבדנו עם בדיקות שנכתבו בQuality Center ועם אוטומציה שהייתה, במקרה הטוב, ראשונית ולא מדהימה, ובדרך כלל פשוט לא הייתה. מתישהו גם ביקשתי, וקיבלתי, קצת זמן כדי לכתוב מחדש כמה מבדקים אוטומטיים בצורה שתאפשר להם לרוץ באופן שיאפשר לנו להבין מה קורה שם.  באופן כללי, הפוקוס שלי היה לנסות להבין את המוצר עליו עבדתי ועל הדרך ללמוד איך לבדוק תוכנה. ובאגים, איזה כיף היה למצוא באגים. 
אחרי בערך שנה הגעתי למקום בו התחלתי להרגיש חוסר נוחות מסויים - עבדתי על המוצר, וחשבתי שעשיתי עבודה לא רעה, אבל הרגשתי שהבסיס התיאורטי שלי לגבי בדיקות תוכנה לא מתקדם לשום מקום וחיפשתי עם המנהל שלי (אחרי חופשת לידה של המנהלת שגייסה אותי וגל קיצוצים, זה היה המנהל השלישי שלי) והגענו למסקנה שאולי הגיע הזמן לבחור קורס, וכיוון שאין שום דבר רלוונטי, ניקח קורס הסמכת CTFL. לא ציפינו להמון ידע חדש, אבל היה תקציב לקורס, ולא היה לנו רעיון טוב יותר. זה כנראה הזמן לומר - עם כל מה שיש לי נגד ההסמכה המצו'קמקת הזו, אפשר לנצל את קורס ההכנה כדי ללמוד דבר או שניים על בדיקות - בתנאי שהמדריך (ובמקרה שלי, מדריכה) מנוסה, אתם ראיתם דבר או שניים בתעשייה ואתם מוכנים לשאול הרבה מאוד "למה" בכל פעם בה החומר הנלמד לא קשור למציאות . יצאתי מהקורס עם רעיונות לכמה שיפורים בדרך בה עבדנו. שלא במפתיע, המשמעות הייתה עוד ניירת. אני חושב שכאן אפשר לסמן את תחילת הזמן בו התחלתי להקדיש תשומת לב לבדיקות תוכנה כמקצוע ותחום ידע בפני עצמו. הסימון הזה כנראה לא מאוד מדוייק, כי כבר באוניברסיטה שמעתי שמועה על זה שצריך לקרוא כל הזמן ולהישאר מעודכנים, ואני די בטוח שעוד קודם לקורס הזה חיפשתי בגוגל כמה בלוגים והתחלתי לקרוא, אבל לדברים האלה לוקח קצת זמן להצטבר. 
ואם כבר אנחנו מדברים על קריאה, השלב השני בקריירה שלי התחיל כשתקלתי בכמה רעיונות של ג'יימס באך ושות', מתוכן הדוגמה הכי מייצגת היא כנראה הוידיאו הזה, והרעיון של אסכולות שונות בבדיקות מאוד קסם לי. כשלמדתי ספרות באוניברסיטה, למדנו על אסכולות, ובאופן ספציפי יותר, על פרדיגמות1
הרעיון של פרדיגמות שונות בבדיקות תוכנה נראה לי שימושי למדי, והחלוקה לחמש אסכולות נשמעה לי נוחה - אסכולת המפעל, שמיוצגת באופן מובהק למדי בסילבוס הבסיסי של ISTQB, מתמקדת בניהול תהליך הבדיקות, ומתייחסת לייצור תוכנה כאל פס-ייצור במפעל, בו עקביות ויכולת חיזוי הם המטרה, יחד עם שיפור בעלויות הבדיקה. האסכולה האקדמית שמתעסקת בשאלות טכניות של מדידת ושיפור הבדיקות באופן מתודולוגי מספקת כלים לאסכולות האחרות שממוקדות ביישום פרקטי של בדיקות בעולם האמיתי. האסכולה האג'ילית שממוקדת בבדיקות מנקודת מבטו של המתכנת, עוזרת להטמיע בדיקות תוכנה בקרב אלו שבדיקות אינן מוקד הקריירה העיקרי שלהם,  אסכולת השומר בשער שמנסה להבין כיצד למנוע מתקלות להגיע לעולם החיצון, מתעסקת בתקנים, במציאת בלמים אפקטיביים ובאיתור תקלות שחמקו. הגבולות בין האסכולה הזו לאסכולת המפעל קצת מטושטשים, אבל אלו שני דגשים חשובים לניהול עסק. האסכולה האחרונה, שלקחה לעצמה את התואר "בדיקות מוכוונות הקשר" (ויש לציין, שיח האסכולות קיים אך ורק אצל אלו שמגדירים את עצמם כחלק מקהילת CDT, אז הם היחידים שזכו לבחור לעצמם שם) שמתמקדת בעיקר בכישורי בודק התוכנה ומתייחסת לבדיקות כאל ביצוע - במשוואה שבין איכות התהליך לטיב בודקי התוכנה, לפרמטר האחרון יש השפעה רבה יותר על אפקטיביות תהליך הבדיקות בחברה. 
הרעיון של CDT מצא חן בעיני מאוד, והוא עודד אותי לחשוב על האופן בו אני בודק תוכנה ועל האופן בו אני מדבר על בדיקות תוכנה עם אחרים. בהדרגה לאורך השנים מרכז תשומת הלב שלי עבר לשאלה הזו - כיצד אני יכול לשפר את האופן בו אני בודק תוכנה. 
במקביל, לקראת סוף 2013, מצאתי את עצמי מתחבר לקהילה המקצועית המקומית. זה התחיל כשעמית לעבודה סיפר לי על מיטאפ בירושלים, וחשבתי שזו יכולה להיות דרך מוצלחת להכיר אנשים ולשמוע על משרות בעיר (אני לא יודע אם כתבתי את זה כאן בעבר, אבל כשהגעתי לעבודה, הייתה לי כוונה מלאה להישאר שם שנה-שנתיים, לצבור קצת ניסיון ואז לחזור לעיר הקודש. מצמוץ ורבע אחר כך, ואני כבר שבע שנים גולה בהרצליה). אז הגעתי, פגשתי כמה אנשים טובים, ומישהו, בואו נקרא לו קובי, הצליח לשכנע אותי להיכנס לפורום בתפוז ולהשתתף קצת בדיונים שם. כן, פייסבוק היה פחות משמעותי אז. מן הון להון, התחלתי להגיע למפגשים, ולדבר עם בודקי תוכנה אחרים. 

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

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

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






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






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 

Friday, February 22, 2019

Exploratory Testing Peer conference 2019 (or: ETC 2019, day 3 - sort of)


As I've mentioned before, I found a way to extend ETC by joining "Exploratory testing peer conference" that was organised by Maaret Pyhäjärvi, Anne-Marie Charrett and Alex Schladebeck. In essence, a full day of people talking about ET and trying to see what does ET mean today, after 30-odd years since the term was coined and kickstart some work to current knowledge to this domain.
Regardless of how would this day go, I learned one thing already: simply ask - I would not be having this experience without asking to join, and I'm very glad I did that. I'm also very thankful for being allowed to join, as it was a great learning experience for me.
I've never been to a peer conference before, and I didn't know what to expect, besides a bunch of smart people (and me) talking in a room, which is usually a great start.
The discussion was facilitated masterfully by Alex, using K-cards and we had an interesting addition to this: we had on the whiteboard the twitter handles of every participant, and noted each time. It looked like so:

This had an interesting effect, at least on me - I was more conscious about giving others time to speak (I received in the past feedback about taking too much "spotlight time" and am trying to be more aware of that) and I could use this tool to actually measure how much do I speak in comparison to others. The answer, which is not in this picture, is that even when I try, and even after asking several times to drop my turn after someone said something similar enough, I still ended up speaking more times than most, if not all, participants.

The subjects themselves were quite versatile: we spoke about sharing intent while mobbing, teaching ET to developers, what happens when good exploratory testers are looking on unit tests, an experience report on trying to integrate ET practices on large scale dark-scrum organization, how to give a 5 minutes elevator pitch on ET and microheuristics. Those are only the topics we got to actually talk about, and there were many more ideas, as can be seen here:

One important feature of the K-cards for such discussions is the blue note (orange in our case, due to logistics), the ability to signal "We're done \ losing focus \ I'm bored" is important and helped us several time during the day. 
Another thing I liked was  that after each discussion (at least in the first half of the day) we did a quick retrospective on the discussion and came up with some improvements. I have never before seen such a large group of people having a discussion that was so well organised. 

Naturally, there are some things I think we can improve for the next time. The main thing is to have a clearer goal for the peer conference. With a topic as vast as ET and with so little time, I felt the need for a narrower question\topic. During one of the breaks, after a discussion that we felt went astray, Lisi and I stood next to the board and tried to see which subjects are in the intended theme of the day (As we understood it) and as you can see in the picture above,  out of the 12 topics on the board at the moment, only 5 were positively there, and 4 were about something completely different that happened to have some ET close to it.  We could either trust the organisers to design a format for the day, or spend a short time box and decide on the way we wanted to do things, but as it was, we started the discussion without agreeing explicitly on our goal, which I think caused some friction. 

One thing I can surely say - If I thought that participating in a conference is an intense experience, this peer-conference took it up a notch. In a larger conference, it is always possible to find some small places to rest - either lose some focus in a talk, or find a corner where the crowd is providing some white-noise. With 24 people in the room, even taking a break is still speaking with the same people, and the mind-work done by actively participating in a discussion is more intense. At some point, just to get some air and let the mind rest a bit I went outside to play catch with Mira. By the end of the day, most of us were a bit depleted, in the most positive way possible. 

Of course, no conference is just ending just when the official time is up, and we all started to walk towards the hotel. In a smaller group, some further discussion was continuing and I think I got to understand better some of the words people were using. Eventually, though, we've decided it was enough, and started talking about getting something to eat. As it happened, I ended up walking with Thomas and Lisi. We just walked about, chilling off and talking. After such an intense day, I felt very recharged just speaking with them quietly. Then we got to a park that had a notice sign - closes in 20:30. As we still had well over an hour, we entered and walked through it for a while. when at 20:00 we got to the gate through which we've entered, we found it locked, as were the next gate and the two after it. We were starting to be slightly worried, but not very much. eventually, we saw someone other than us in the park, and could see an open gate. From there we could walk back to the city center and had a nice dinner. A great way to finish the day. 

Monday, February 18, 2019

ETC 2019 - day 2

Sketch by Marianne Duijst


So, after going to sleep somewhere around 01:30, I woke up for a completely new conference day, and I even got almost 6 hours of sleep, which is quite good for a conference night.
I met with Mor for breakfast and we headed to the conference venue. Today’s opening keynote was Dr. Sal Freundenberg’s story on getting back to working as a coder after a long time of doing other things, and to make things more interesting, she was doing that while ticking some checkboxes that make hiring harder even without such a break – being older, female, and autistic. What I liked in this keynote was how she took action to her own hands and took conscious steps to get her goal – Older (and experienced)? That means there are friends she could pair with to brush off the rust and reacquaint with the current tools & trends. Problem with bright lights, big crowds and loud noises? Find a place that works remotely and customize the workspace (I really liked the fidget things on the table). All in all, it showed that getting back after a long pause is possible, and at least by the way it was told – there can be a lot of fun in doing so.
Then it was time for the workshops – I chose to participate in Anne-Marie Charrett’s workshop about exploring an API. Right at the beginning I was informed that the focus of this workshop would be the opposite of what I hoped for and would be an introduction to restful APIs and show how they can be explored, rather than to assume familiarity with APIs and systematically exploring one. I decided to stay, since even in this case I could still see some of Anne-Marie’s ideas of exploration and use them to learn. I wasn’t disappointed – we started by modeling the application under test (found in http://automationintesting.online ) we then started questioning the model and using the software to get some answers. We missed a bit of the instructions and started only to form the questions, but it was valuable nonetheless.
After the workshop I went to Clare Sudbury’s talk about how not having unit tests for a game she was creating for herself came back to bite her in the rear and how she used pairing to keep herself honest and avoid costly shortcuts. I really wish I could convey the feeling she projected in the room and pass it on to everyone who thinks unit tests are a waste of time, since the dry facts don’t do this story any justice at all. The animated GIFs were a nice addition.
I stayed in the same room in order to listen to the next talk: "playing port authority", which was about "unit testing" your docker configuration files. From all of the events I attended, this is the only one I was disappointed with, probably due to having wrong expectations – This talk was about a specific tool, written in Ruby. While this tool does seem to provide some nice shortcuts, it does not really do anything revolutionary or even interesting, and I say that as a person who is completely unfamiliar with Docker beyond the basic concept. Those tests are long (makes sense, since the setup is “deploy a container, installed whatever is needed”) and all the tool is doing is to wrap Docker API in order to provide some verification. If I ever face the need to test containers in such manner and I happen to be working in a language other than Ruby, I’ll probably go and write my own wrapper around it instead of adding another language to the soup. Things that would have made this talk better for me would have been answers to questions such as “Why would I want to perform such verification instead of checking it once and run faster checks on the docker yaml file? When it is appropriate to use? When it isn’t? What concepts make this specific tool better than what’s out there? What would I have to implement myself if I am not using Ruby? When is it appropriate to run such tests? What sort of infrastructure is required to gain benefit from such tests?
As it was, it’s been “just another tool” talk, and I am less connected to such talks.
But, no worry – after a short coffee break came the time for open space, which I have never seen go wrong. This time was different only in one thing – I managed to avoid suggesting a session myself. There were so many other sessions that were interesting. Since my coding fingers were tingling, I participated in Maaret’s session on exploring with unit tests where we used Emily Bach's Gilded Rose Kata as our target. It was interesting and I think I got a thing or two about using unit tests from it. I then moved to a discussion about contributing to open source projects, and seeing that I don’t add or gain value there I invoked the rule of 2 feet and moved to the middle of a session by Jessica Davis about “tips for the new tester”, the session was briefly hijacked in order to help another tester with about a year of experience to set up expectations and prepare for onboarding a senior tester to the team. After the session has dispersed we continued to chat a bit around this and I provided whatever opinions I had (which, as those reading here probably know, are not very intelligent, but sometimes sounds convincing).
After the open space time-slot has ended, it was time for the closing keynote. This time – Ash Coleman’s Story of being a minority in tech. I cannot stress enough the importance of this talk, which speaks, as you might have guessed, about diversity and inclusion. Most of the time it’s easy to dismiss diversity issues with a plethora of excuses (those are the people we find, or those are the only who are staying, or anything else. But in fact, the reasons behind such excuses are that that place probably has some unconscious ways of excluding people different than the mainstream. It might be assigning value to irrelevant properties (“His salary is higher because he has a degree from a top-college” is an example – if people are doing the same kind of work with the same skills, it really shouldn’t matter where did they get those skills). My main takeaway from that was that difficulties that are common for an underrepresented group are usually ignored, misunderstood or dismissed by people of the dominant group, thus prolonging the inequality. I went to ask Ash later what can I do to mitigate this blindness, and her answer was to find in my environment someone I can trust who is part of such underrepresented group and ask them to tell me when I’m missing something, mirror to me my behavior or ask explicitly for my help in cases where I’m not seeing the need for such. I’m keeping this advice with me.
That’s it. The conference was done. Now it was time to say thank you and goodbye to a lot of people. I helped clean the auditorium (a fun part of that was to peel Marianne’s sketches from the walls and roll them up). Somewhere around that time I Asked Maaret about that peer workshop she mentioned during the open space and asked if I can squeeze in (The answer was yes, for which I’m grateful). After that I took a short while to rest in my room and joined a large group of people (including a few who were not at the conference but came to participate in the peer workshop) in a bar somewhere in the city center. We chatted a bit, had some fun and some drinks, then went to another place to eat.
Dinner was great – a whole lot of people that I wish I could spend some more time with. I don’t remember how we started speaking about languages, but we were all thrilled to learn that the same word (“rahat”) is used in Finnish to indicate money and in Romanian it means “poop” (There was a story about a parking tickets machine that asked for money, but i don't recall the exact term or it's translation from Romanian to English, maybe "Loud poop" or something like that). By the end of the evening I found myself with Lisi, Kristine & Jessica who told us how she got around to be in this conference (and her way into testing, as well). Kind of a cool story, I think.
Back at the hotel, some people were still at the lobby. I got to listen to Marit, Sarah, Franzi and Clare talk about difficulties in the work place that males do not experience.
An important reminder to any male readers – The fact that you are allowed to listen to such a conversation is not an invitation to sound your own opinions. It might be ok to ask a question here and there, but generally the right thing to do is to STFU and listen. Who knows, you might learn something new. I, for example, learned about the concept of a sponsor in a workplace and why is it important.
Then – sleep before the peer workshop starts, and more on this - in a later post. 

Sunday, February 17, 2019

ETC 2019 - day 1

Source: Sarah J. Wells keynote slides

So, European Testing Conference 2019 is officially done, and what a blast it was.
There's so much that went on, so I'll start with a short summary - I got to meet and connect with great people - some of which I've met before, others I met for the first time. Selecting which content I wanted to listen to was harder than ever as the talks topics was superb and I got out with a few insights from both official content and just talking to people. If you weren't there - your loss, and you should remedy this next year.

A tiny tip for conferences - if you can, stay at the conference hotel (Sometimes it's official, in other times it's just the hotel closest to to conference) as it will enable you to have a little bit more time to connect with people over breakfast. I started my first morning with a short chat with Alina Ionescu, which apart from being a pretty cool person in and of herself is also part of the team that created ETC (and if my memory serves me well, has been doing this in the past 4 years as well). We didn't have a lot of time to chat because mornings are hard, and she had to go and organise some last things at the conference venue, but it was still a pleasurable start of the day.
I took a bit longer and got in time for registration, managed to say hi to some familiar faces and went to listen to the opening keynote by Angie Jones. Angie's talk has been quite different from my expectations, in a very good way. The talk was a story of a challenge that was just too much to overcome and the problem remained unsolved. The full talk will be online somewhere in the (I hope near) future, but I took from it a couple of things:
First of all, it was a reminder that culture is stronger than any single person, no matter how talented or creative they are. Second, there isn't yet any constructive way of speaking about testability - what it is and how to approach it. As for now, the best attempt I've seen is the 10 Ps model (There's probably a better link somewhere, I didn't find one) which is a great way to expand many aspect of it, but still very abstract in nature. All in all, it was a thought provoking keynote. Just the right way to kick-off a conference.
We then moved to the second building - the venue was, sadly, split in a manner that required getting out to the street to get from one part to the other. Normally I would assume that this is a major setback that will interfere with connecting people, but the organising team proved once again that when's there a will, there's a way, and I didn't see any such effects. In fact, their choice to leave the central auditorium empty during regular session time provided a very nice place to sit and speak with someone when we needed some quiet from the crowd. Anyway, back to the session. I went to a talk about contract testing for a microservice environment. It was a very good talk for me, since it dealt with a problem-space close to me, and presented an intricate implementation of an idea that I need to investigate a bit further. I'm not sure I understood exactly how is the mechanism works and where exactly it it beneficial to apply contract testing, but every talk that leaves me with some homework to do is a good one.
Then - running back for speed meet. This format is tough, and I like that the organisers still experiment with it. On one hand, it's a great way to create some new familiar faces and break the ice in a safe environment. On the other, it's very loud and crowded, easily creating sensory overload and easily  draining a lot of energy from introverts and ambiverts. This has made the announcement at the beginning ("If at any time you feel you want to leave, just do so") very important. I liked the standing-up setup we had this year - no more fussing with chairs, and the acoustics of the hall made it a bit less noisy than last year, even though there were more attendees (I think). There are still things I think we can improve - Slowing down and providing a bit more than a minute is one thing I might consider - meeting 20 new faces in quick succession is great, but that can be a lot, and one minute is very difficult to manage. Second, I wonder about the mind maps - it's just too easy to hide behind them instead of having a short conversation, perhaps a more condensed format (such as "three words related to you") will be more effective in creating some face-to-face conversation and not face-to-paper one. Still, despite everything, the main goal is clearly working - after the speed meet there are a lot of new familiar faces, and the choice to make it just before lunch is nothing short of genius, to allow people to continue conversations in a more relaxed situation.
I skipped the next track of sessions - and instead sat to speak with Kristine about SpeakEasy (I ended up agreeing to help two new mentees,  which is rather cool). Then we moved again to lean coffee - my favorite activity by far - and then the closing keynote for that day.
Sarah J. Welles told a fascinating story about the challenges and insights we face when working in a fast-releasing environment. For instance, did you know that some sharks really like the taste of the Vietnamese internet cables? This talk, like other CD tales I've heard in the past, left me thinking about what can be taken from those systems to a higher risk, slightly higher regulated environment and what would be the stepping stones in the way. Slow & big releases are painful.

A closing keynote means end of the day, right? Not in ETC. There was a conference party\dinner\something going on. There was food, there were people, there was time to chat and process. I got to speak with new people and had time to speak with some friends as well. Somehow it just happened that I found myself so immersed in a conversation that I didn't notice there were closing the venue, When we did notice that we simply moved to speak in a nearby tapas bar - it was not that we were hungry, but rather just wanted to continue talking. By 23:00 we decided that the smart thing to do would actually be to go to sleep. So we went to our hotels.
Well, remember what I've said about using the conference hotel to extend the conference? I saw some people sitting in the lobby and thought "I can say hi for a couple of minutes".
90 minutes later we called it a night and went to sleep.

This ended my first ETC day - fully packed and positively exhausting.

Thursday, February 14, 2019

ETC 2019, day 0


So, it's ETC time of the year again, this time in Valencia.
As usual, I took a couple of days to get to know the area and do some touristy stuff.
I got here by Monday evening, dropped my bags at the hotel and went for a short tour around to get a feeling of direction and of the environment. One thing I've noticed here is that people around here don't English well. Or, in fact, almost at all - The little time I've spent using Duolingo was sort of paying off when I could tell people "I'm sorry, I don't speak Spanish" (Or, in the short version: "Excuse me, English?")
Anyway, I found something to eat and went to sleep a while.
Tuesday was when my plan actually started. When travelling I always have the same plan: Walk until My feet fall off, and then some.
I started with a walking tour, which gives me both the opportunity to walk around a bit and to make a quick checklist of interesting things. For example, one thing I've learned is that a bat and a dragon are, essentially, the same thing. At least in Heraldry, both signify protection, and since it is easier to draw a bat in a frontal position (or maybe, because when you draw a dragon in that position it looks very much like a bat) then the two of those are kinda merged, and one can see how over time a front facing dragon will turn to be a bat. So, if you ever wondered why does Valencia have a bat as part of it's shield - now you know.
Another thing I got from the trip is a recommendation to try a local drink called "horchata", with the warning that either you like it, or you really don't. Apparently, I really don't. The other beverage that was mentioned, which is an alcoholic one, is "agua de Valencia" (Valencia's water) which is a nice cocktail that has the important property of not tasting like strong alcohol.
After the tour I wandered a bit more, found a place where I could buy a charger for my computer to replace the one I forgot back at home  (Well, almost, my laptop is a monster requires 170W and the strongest they had was 120W, which is enough to keep my computer from draining and charge it while it's off) and then I went to climb the stairs of Micalet, a bell-tower with a nice view of the city roofs. Micalet which is Valencian (A language that is still taught at schools in the region) for "little Michael" (I think that in Spanish it's "El Miguelte"). The bell itself is little in the same sense that little John is - It's a heavy metallic monster, the biggest in the area.
After climbing those 207 narrow stairs, and then down, I relaxed a bit by going to the ceramic museum - Some nice things in exhibition, but I was hoping for some more detailed explanations or a coherent story or something. Still, a nice place to be in.
Dinner, then sleep.
Wednesday I started by walking through the park from my hotel in city center to the Science museum near the beach. It's a nice park, and the walk was a leisurely paced stroll of ~30 minutes, so I enjoyed it a lot. The science museum was rather nice, even if some exhibitions were being disassembled. I went out feeling that it's a nice start, but can be a bit more. As I was already there, I took a trip to the oceanografic -Basically, an aquarium. I made a mistake and assumed that since it was partnering with several projects aimed for ocean preservation it won't be one of those aquariums that is essentially a zoo - holding many marine species out of their context (there's a nice one in Vancouver where they treat animal and try to restore as many as possible to nature). Visiting there didn't seem like it was doing anything like that, so in retrospective I should have checked more thoroughly. It also can be that I got a false impression, so if you care about those things and consider going to the Oceanografic, do your research better than I did.
After the visit I strolled towards the beach, where I stumbled upon Lisa Crispin who introduced me to the rest of the gang that was hanging out there. I ended up walking back to the hotel with Kristine and we had an adventure trying to figure out the city-bike rental scheme. We didn't manage to do that and settled on a bus, but it was a lot of fun nonetheless. Naturally, we didn't go straight back to the hotel, but stopped to meet a bunch of people for dinner. So, in a manner of speaking, the conference has begun.
So,  Happy ETC to everyone!

Saturday, January 12, 2019

שייחנק הלקוח



English version

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

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

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

Eff the user



This idea has been running in my head for a while, and every so often I'll stumble upon a reminder to write something about it, and then have other things to occupy me. The most recent trigger was a talk by Joel Montvelisky in a local SIGiST conference where he spoke about the changing role of the testers. The subject is my objection to one of the modern testing principles.  I'll admit - I really like them. That is, with the exception of principle #5: "We believe that the customer is the only one capable to judge and evaluate the quality of our product".
I don't like this one a tiny single bit. I think it's a false statement and it drives wrong team behaviour and goal displacement. Worse, this idea seems to be ubiquitous in the industry, or at least wildly spread, as some of the variants of similar ideas out there show. I think that #5 is one of the most carefully worded expressions of this idea (as one cannot dismiss it with "a tester can't be a customer proxy\champion\advocate") So I'll stick with it when thinking through my disagreement. 
On the face of it, the principle is very solid - if we accept Jerry Weinberg's notion of quality being value to some person (and I like Bach's addendum to it), it only makes sense that the person who is getting the value is the best judge of it. 
Except when they aren't.
I am not claiming here that a product that is not used or bought by any of its target audience can claim to be "of high quality", but simply that there are cases where evaluating the quality of a product is something that the customer is not capable of doing. 
Imagine that you are getting an OS update to your phone. It improves memory management, fixes a security flaw and provides better logging in cases of a crash. Are you in any position to evaluate any of this? Would an average phone user be in such position? All of it brings value - better logging means faster debugging cycles and faster hotfix releases, a security update reduces the likelihood of the phone being hacked and the memory management improvement will mean you could run more applications in parallel and avoid lagging. But how do you even notice any of those? You don't see the crash reports (and there are other ways to improve response time), the security update is like an insurance - you only notice it if something bad happens, and  your phone has enough memory that you didn't notice any problem with the previous memory management scheme. In all of those examples, there are simply too many layers of indirection between the actual property and the perceivable result and the quality of the product, if assessed by the customer, must be assessed by a proxy measurement. In some cases, the customer might notice if you did a shitty job, but the distinction between "barely good enough" and "excellent" is not visible. 
Then there's the ambiguity about "who is the customer". Consider a bug fix that eliminates a scenario where the user is charged for only 3/4 of the actual use. By fixing it, we are taking "value" from the product's user, but adding value to the vendor. While such condition is extreme, there are more examples when one looks on B2B products - The full disk encryption scheme used by our IT department makes our computers freeze for a second every now and then, but provides the decision makers (who don't use their PC as intensely as other employees do) the peace of mind knowing that data could not be leaked by simply stealing a PC. Customer value? high. User value - not so much.

Now, to goal displacement and wrong team behaviour. A simplistic understanding of this principle drives a lot of focused into perceived quality and requires advanced logic-fu to justify any kind of improvement that isn't a new feature. Take for example an architecture improvement for enabling our product to scale to need. We can go with the current architecture for a year or so, and probably throw more hardware on it for the next five years, so, no real benefit to the user, let's not do that. The rule-fu required would be something along these lines:  "If we don't do it then we can probably patch the system for 5 years but it will gradually slow us down as we deal with issues as they appear, and will also be exposing customers to issues caused by this load. In addition, in five years time we'll have more components relying on the old architecture we want to replace, so the change will take longer and be more risky and complex". This sort of logic is not trivial and far from immediate, if we train our instincts to zero in on the customer satisfaction we'll have a tough time coming up with such scenarios, let alone justify such future-looking actions in face of a well trained gut-feeling. Most teams don't need another thing applying pressure and bias towards perceivable features. True, if we insist, everything we do has an ultimate impact on the customer, but sometimes the impact of good engineering practices is several times removed from the actual impact, and it will usually be only one of the factors affecting that specific property of customer value. Imagine two similar SaaS products, both have the same capabilities, a similar size of customers and are distinguishable only by minor features that might appeal more to someone's personal taste. One product is built by a team of 10 highly skilled engineers that are running a tight ship. The 2nd is maintained by 100 people who work frantically to keep things afloat. The cost of operation for the two products is similar - The top notch engineers are getting payed 10 times as the less skilled ones, and the robust hardware and hosting services used by the first team are as expensive as the cost of throwing cheaper hardware  to gap for design problems in the second team. The perceived quality is the same, both companies can scale at roughly the same pace with roughly the same resources - is the quality of the two products equal? They are supplying the same customer value in different means, only the 2nd team is making it really difficult for their operations team.
I got a response for similar claim from Joel who said "The operations team are your customers as well".
Well, no.
Up until this point in the text we equated the development team to the company. By claiming that someone internal (be it operations, marketing or product management) is also a customer we are shifting our focus to the development team.
Let me say it clearly: As development team we don't have customers. We have employers and colleagues. Calling them "customers" might be useful when trying to convey the message that we provide a service to our colleagues and employers, but is otherwise causing confusion.  As employees we are getting a salary to promote the interests of our employer and that's it. I won't get a lower salary because my employer is unhappy with my work this month, and the contract between us have different obligations than those between a service provider and a customer. If I'm working towards my employer's interests it is time to face the cynical truth - most companies care about the customer only in terms of financial gain and a customer is nothing more than a walking bag of cash. Sure, it's very difficult to have a profitable product that does not align well with the customer's needs but when the two values are in conflict, I should be choosing the (long term) monetary1 business value over customer satisfaction.

So, Short version: Perceivable quality is not quality and it's important to remember that the customer is a (very important) mean to achieve our goals, but not the goal itself.



1 Thanks to Brent Jensen for reminding me that business value could be more than simply monetary. It's a bit harder to measure, and I believe it makes the point even more relevant - this business value could be the company's reputation, business contacts or even its moral values, for those fortunate enough to work in a company that cares about those