בודקי תוכנה זה דבר מיותר

 

English

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

1. אין צורך במומחיות. ברוב המקומות בהם הייתי, לפחות 95% מעבודת הבדיקות שנעשתה, וזו שהייתה צריכה להיעשות, הייתה ברמה שבודק תוכנה מתחיל היה יכול לבצע, או ביצע בפועל. המשמעות של זה היא שאנשים בלי הכשרה יכולים לבצע את המשימות האלה בקלות יחסית, או לכל היותר אחרי הדרכה קצרה וקצת תרגול. נכון, ישנם מקרים בהם באמת נדרשת מחשבה מעמיקה או מומחיות - כשצריך להגדיר אסטרטגיה לפרוייקט גדול או מורכב במיוחד, כשצריך להבין איך לבדוק מוצר קשה לבדיקה או פיצ'ר מסובך במיוחד. שם נזדקק לבודק תוכנה מומחה, אבל המקרים האלה נדירים. 
2. הסרת אחריות - כשיש מישהו שתפקידו הוא למצוא את הבעיות, שאר האנשים בסביבה יכולים להרשות לעצמם להיות קצת פחות זהירים, גם כשזה לא קורה באופן מודע. הם מגישים את התוצרים שלהם "לבדיקה", אז לא צריך להיזהר מאוד - מקסימום, יעזרו לי למצוא את הטעויות. 
3. הסחת יעדים -  אם יש אדם אחד שאחראי לכתוב תוכנה ואחר שאחראי לבדוק אותה, כל אחד מהם נמדד על הביצועים שלו בתחום האחריות הספציפי הזה. המטרה המשותפת שלהם - להוציא לשוק את התוכנה הנכונה במהירות האפשרית - לא שייכת לאף אחד. לאחד יש "דאג לספק תוכנה בקצב מהיר, ואילו לאחר יש "ודא שהתוכנה כתובה כיאות", וזה אם יש לנו מזל. במקומות מסויימים, היעד כפי שהוא משודר בפועל הוא "מצא סיבות טובות לעכב את שחרור המוצר". זה יכול להוביל למגוון בעיות התנהגותיות, ולקושי בשיפור כאשר כל צד מנסה לשפר את החלק שלו ולא מסתכל על המערכת בכללותה. אי שם לפני קצת פחות מעשור זכיתי לחוות את השינוי הזה בצוות בו הייתי. את הפיצ'ר אני כבר לא זוכר, אבל אני זוכר שכחלק מתכנון העבודה, ביקשתי לשנות את המימוש כך שחלק מסויים יהיה חשוף החוצה כך שיהיה קל יותר לבדוק חלק משמעותי של הלוגיקה. המתכנת שהיה אחראי על כתיבת החלק הנ"ל, התנגד. קודם כל, הוא כבר התחיל בכיוון מסויים, וזה לא נכון לעוות את התוכנה רק בגלל צורכי בדיקות, ובכלל, הנה כמה סיבות שנשמעות די משכנעות בגללן נכון יותר להישאר עם הבחירות הנוכחיות. אז קצת יותר קשה לבדוק את זה? נו, שוין.  רצה הגורל, ובגלל בעיות עומס, אותו מתכנת קיבל גם את המשימה של לבדוק את הפיצ'ר. גם כי היה עמוס, וגם כי היינו בשלב מתקדם יחסית של מעבר לצוות נטול תפקידים, בו כל חברי הצוות הם "מהנדסי תוכנה" או משהו כזה. כמה ימים אחר כך, במהלך הדיילי, הוא סיפר שהוא הסתבך קצת עם בדיקת הפיצ'ר, ומצא פיתרון יצירתי שהפך את הבעיה לטריוויאלית. בגדול? אותו דבר שביקשתי ממנו קודם. כל הטיעונים הטובים מקודם הפכו פתאום להיות פחות חשובים מאשר לשמור על קוד קל לתחזוקה ולבדיקה. 
4. לולאת משוב ארוכה יותר. לא משנה איך מסובבים את זה, או כמה טוב התיאום בין חברי הצוות, לולאת משוב שכוללת שני אנשים תהיה איטית יותר מכזו שכוללת אדם אחד. כאשר אותו אדם שמבצע עבודה גם בודק את התוצאה, יש לנו סיכוי הרבה יותר טוב לראות התנהגות של "בדוק, תקן, בדוק שוב". גם הפעולה בעקבות המשוב זורמת הרבה יותר - לא צריך לשכנע אף אחד שהבעיה אמיתית, ולא צריך לבזבז זמן על הסברים כמו "איך לשחזר את זה?". זה יכול גם לקרות כאשר כמה אנשים עובדים יחד - כאשר הם עובדים יחד על אותה משימה, בזוג או באנסמבל.
5. ריבוי צווארי בקבוק פוטנציאליים - אם יש לנו פונקציה ייעודית של בודק תוכנה, יש לנו עוד קודקוד בגרף התקשורת שלנו ובגרף התלויות - כלומר, יש יותר מסלולים שצריך לוודא שעובדים, יותר פקקים שיכולים להיווצר ויותר מקום לטעויות. מבנה פשוט יותר תמיד עדיף, כאשר הוא מתאפשר.
6. יש ראיות אמפיריות שמוכיחות את זה. ספציפית, אם אנחנו קוראים את מה שכתבו מחברי accelerate נראה שהם מוצאים קורלציה חזקה בין הצלחת החברות לבין זה שמי שכותב ומתחזק את הבדיקות האוטומטיות הוא אותו אדם שכותב את הקוד למוצר. ומה לגבי בדיקות שאינן אוטומטיות? ובכן, הם מאוד דיפלומטיים שם, ולא מזכירים את הנושא לטוב או לרע. מספיק לזכור אולי שהספר הזה מסכם כמה שנים של סקר בשם state of devops כדי להבין שאין בעולם שלהם המון מקום לבדיקות שאינן אוטומטיות. 

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

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

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

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

אני מקווה שהטיעונים האלה משכנעים אתכם לפחות כמו שהם משכנעים אותי, אבל גם אם לא, 

Testers should not be

עברית

People who heard me speak about testing, or noticed what I wrote  here, for example, might know that I believe most companies should strive to get rid of dedicated testers. I think it's time to put some more words to it. There aren't that many reasons, but I find them convincing, and hope you will too.

1. No specialization required. In most places I've seen, at least 95% of the testing work can either be done or is being done by junior testers -  people without a lot of experience, and any skill they might possess can be taught to just about any software professional with relative ease. There are some cases where we need to define a strategy for a large project, or find a way to deal with large amounts of data, or cases where it's hard to define "correct". In those cases we might need an expert tester - but those are the rarity. 
2. Abdication of responsibility - when there's someone whose role is to find problems, the rest of the people are less careful. Even when they don't mean to. They submit their artifacts for "testing", so they assume they need to do very little of it themselves. 
3. Goal displacement - when there's one person writing code and another testing it, no one actually has the supposed shared goal - "deliver the right thing at a good pace". One has "deliver at a good pace", the other has "deliver the right thing" (if we're lucky, it might be "find reasons to delay the delivery"). This can lead to strange behaviors, that are perhaps best illustrated in an experience I had about eight or nine years ago, when I spent some time asking a developer to change the design of a feature in order to make it easier to test. His response was "it's not right to change design just for testing, and here are a few reasons why the current design is preferred". This very reasonable (yet wrong) response flew out of the window a couple of weeks later when the same developer was tasked testing the feature (we were transitioning to a role-less development team, which worked really well, I think) and after struggling for a few days, he came to the daily standup saying "I was having trouble testing the feature, so I made some changes to the design and now it's easy to test". All the good reasons suddenly were less important than having maintainable (which includes easy to test) code.
   We don't want people in the team to have different goals, unless it's really necessary.
4. longer feedback loop. It doesn't matter how hard we collaborate, how good are our tools and practices, getting the feedback from someone else almost always adds some overhead to the feedback loop. when we have the same person who does the work also verifying the job is done well, we get a faster feedback loop, and action is taken on that feedback more easily. We are much more likely to see the loop of "test-tinker-test" when the same people are doing both tasks (either as a pair or ensemble comprised of different skilled people, or as a homogenous group of one or more people)
5. More (potential) bottlenecks - with a dedicated tester, we've just made another vertex in our communication  and dependency graphs. This means that there's one more party to update and hope no significant information gets lost, and there's one more kind of work that we need to coordinate with the rest of the work. 
6. There is some empiric evidence this is the case, I'm familiar with the claims in "accelerate" (that have been very careful to narrow their scope to "automated tests", but I suspect this choice is a political one, as they don't mention any other kinds of testing that has any correlation to business success)

Ok, let that sink for a while. I can hear some rant in the distance, rambling about "What about the tester's mindset??", and there are a few examples where dedicated testers are simply a must and I'm sure they jump into your mind. As for the first objection - there isn't a thing like that. Testing, and the thinking associated with it are skills that are being taught and honed by experience that includes focus on risk seeking. In this aspect, a developer with a decade of experience will probably do a better work testing than most testers with two or three years under their belt. 

The second point, however, holds true, and this is why I believe only "most" companies can do without dedicated testers, and not all of them. The most notable example I've met is while I was interviewing for the team I was at a few years ago. The interviewee held a masters degree in physics and was testing a ground radar. His day job included a lot of calculations and applying his knowledge - knowledge the developers didn't have, nor did they have the time to acquire it. This is probably the only situation I can think of where having separate testers is more efficient than making testing a part of the creator's work. There might be some constraints that would make having dedicated testers a good choice for the time - we might not have the right culture, or we might be testing an application that we pay someone to develop and we don't trust their testing is good enough for us, or our budget and reporting mechanism might encourage us to behave in that way -  but those are conditions that should be eliminated over the longer term.

I hope you find those arguments convincing as much as I do, but even if you disagree, I hope it helps to understand my stance on dedicated testers.

Next: Why, despite those thoughts, I identify as a tester and invest effort in becoming better at it.

ושוב איתכם

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

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

אז התחלתי, באופן רשמי, באפריל האחרון. עד אז הייתי בצוות כבר תשעה חודשים, ולפחות באופן רשמי, נוהלנו באופן ישיר על ידי ראש הקבוצה שתפקד כראש צוות זמני. יש סיבות טובות לעיכוב הזה במינוי ראש צוות קבוע - כשלוקחים סטארט-אפ ברמת תפקוד ישראלית סטנדרטית ומצרפים אותו לתאגיד אמריקאי לא קטן, יש לא מעט שריפות שצריך לכבות בכל מיני צוותים, יש אנשים אחרים שעוזבים וצריך למלא את התקן שלהם, וצוות קטן וחדש שלא גוזל המון קשב ניהולי ובונה את עצמו בשקט יחסי בינתיים הוא לא הבעיה הכי דחופה. חוץ מזה, כמו שיודע כל מי שניסה לגייס אנשי בדיקות - השוק מלא במועמדים לא טובים מספיק, והדבר נכון שבעתיים לגבי ראש צוות. וכן, אני מניח שגם לזה שהייתי שם כדי לסתום חלק מהחורים שהיעדר מנהל משאיר בדרך כלל עזר קצת להפוך את המצב לנסבל. חוץ מזה, בשנתיים האחרונות הכל התנהל לפי סדר עדיפויות אחר לגמרי בכל המדינה. בכל מקרה, הדבר הכי נכון כדי למלא את המשימה שלי - להקל על המנהל שלי ולעזור לו להשיג את המטרות שלו בארגון - היה לקבל ניהול פורמלי של הצוות. אני לא בטוח אם קראתם את הפוסט של תומר על תסמונת המתחזה אבל הוא לגמרי צודק - תסמונת המתחזה אף פעם לא הולכת, גם לא אחרי עשור של חיזוקים חיוביים, למידה והצלחות בעבודה. ידעתי שעדיין לא פיתחתי את הכישורים הדרושים לעבודה החדשה, ושאני אפילו לא יודע עדיין במה היא שונה מהתפקידים הטכניים שביצעתי קודם.  מה שכן משתפר עם הידע והניסיון הם מנגנוני ההתמודדות עם ההרגשה הזו - אחרי התחושה הראשונית של "שיט, למה נכנסתי?" מנגנוני החשיבה האיטית נכנסים לפעולה ואני יכול לשים לב לכך שזו לא רק חוויה מפחידה, אלא גם הזדמנות צמיחה מצויינת. או לזכור שאני אולי לא יודע לנהל, אבל היו לי גם מנהלים טובים וגם מנהלים טובים פחות, ושאני יודע לזהות חלק מהמאפיינים של אלה או של אלה, שלאורך השנים קראתי והקשבתי ללא מעט תוכן שכלל גם פילוסופיה של ניהול צוות ושבסופו של יום, יש לי מנהל ישיר שאני יכול להיעזר בו. בנוסף, גם הידיעה שעד היום האסטרטגיה של fake it until you make it עבדה לי היטב, ושהחלקים נרחבים בעבודה היומיומית הם דברים שהתנסיתי בהם בעבר - כמוביל טכני יצא לי לעזור לאנשים לפתח את הכישורים שלהם, לכוון את העבודה הטכנית , לבנות backlog של משימות ואפילו לשבת לשיחות 1X1 עם אנשים. יש עדיין לא מעט חלקים חדשים, כמו לדעת מה עושה כל חבר צוות, או להעריך את תפקוד הצוות והחברים בו ולשפר אותם, או לתת פידבק לאנשים גם כשהם לא מגיעים אלי כדי לבקש אותו, אבל אני יכול להישען על החלקים שאני כבר יודע לעשות כדי ליצור איזו שגרה בתוכה אני יכול לתת שירות טוב מספיק בעודי משפר את החלקים החדשים ומגלה מה עוד אני לא יודע. זה גם עוזר שאני יודע מה אני רוצה לעשות כמנהל - אני רוצה לקדם את הרמה המקצועית בצוות ולתת לעובדים סביבה בה הם ירגישו שמקשיבים להם, ושהם מתפתחים ומשפיעים. אני רוצה לפנות להם את הזמן לעבוד ולא להתעסק בשטויות מעבר למה שצריך' ואם אפשר, לתת להם להתמודד עם משימות שיאתגרו אותם בדיוק מספיק כדי לצמוח.

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

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

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

Hi again

 It's been a while since I last wrote here. A bit over a year, in fact, and I have many excuses. Truth is, some things have caught my attention and I dropped the habit of writing here, I think I want to catch up again on it. 

One of the things that happened in the past year, is that I was asked to lead the team I was in. Becoming a manager was something I have avoided so far since I was in a position to enjoy most of the fun parts of managing without the tedious or annoying parts. It was also an inertia thing - I started wanting to avoid managing at almost all costs, and having expressed that clearly and loudly, people around that kept assuming this was my position even when I started to warm up to the idea in the past few years when I got to experience more of the fun parts about managing. 

I officially started last April. By then, I was about 9 months into my new place, and my team was being managed by our group leader as an interim team lead. There have been a lot of reasons for this delay - we were a start up acquired by a corporate, there were other teams that needed attention, and finding a decent manager for a testing team is a difficult task. There were also external factors that took our attention. So, true to my claim of doing my best to help my manager in whatever way - I agreed to fill the gap. Despite having over a decade of good (and bad) managers, of functioning as a tech lead and mentoring team members, I felt unprepared for the task. After all, it's the first time that other I had such a direct impact on other people's careers. It is now up to me not only to provide guidance when asked or when I feel like it, but to actively evaluate the skills of the team members, identify gaps in the team and have a plan to fill them. It's also the first time I needed to define future plans that were not relying solely on my execution abilities but had to factor in the ability of other people to complete their work, based on their skills that I have no idea how to evaluate. One advantage I did have is that I knew, in theory, what was important for me as a manager. Specifically, I want to focus on nurturing my team into one I'll be proud to be a part of (which, to be frank, was not the starting condition, and was one of the reasons I was asked to join and then to manage) and my way of doing that is to try to provide my team members with what I got from my good managers and what I was missing from the less proficient ones - a sense of direction (what should they be doing next and why), coaching on their tasks - including feedback and help when needed, but allowing them to stretch their skills and a safe environment where they'd know they are heard.

Knowing something in theory, even if I  read about it in a book or a dozen, is very different than actually living up to it. I found out how difficult is to tell someone they need to improve without getting them defensive is a challenge, and keeping tabs on who does what at any given time is a lot even with just four people in my team. Add to that maintaining a backlog for the team, some code reviews and still taking a task every now and then, and I'm stretched pretty thin. On top of that I still need to raise my head above water and take the long-term view, which is a skill I'm still learning. So, great fun all around. 

As is my approach with most tasks in the recent years, I'm building from the things I know - I'm ok in coaching and in the technical aspects of the work,  I had the chance to practice one on ones in my previous workplace and for some odd reason, I'm good at making people think I listen to them (even when I don't, but I am honestly trying), I am also relying on my manager to take care of  some aspects I don't have the attention span to do now such as figuring out whether we have need for another person on the team or forcing me to stop and consider whether the work we're doing is effective. 

It's a new experience for me, and it really makes me wonder - it's not uncommon to see people transitioning to the management track early on in their careers - how much impact does this have on their technical abilities? I'm in a relatively relaxed situation - not a lot of team members, our deadlines are meaningful, but they don't  threaten to run the company out of business if we miss them, and still I find very little time to dedicate to the technical aspects of work, and mostly rely on the skills I've built in the past  decade or so.  Can a manager without such experience transition back to an IC role if they don't have such a foundation? It really makes me reevaluate the way I interpret CV's - managing a team, even a small one, strengthens a lot of leadership and bureaucratic skills, but even when being super involved in the technical aspects, it's still fairly limited. While I have no doubt that if asked, people in my team will say I'm into every detail of their work, that's true only in the superficial sense - Hopping around that many topics is preventing the deep diving into details needed for true work to happen - so I comment, I skim occasionally, and mainly - I rely on the tasks beings similar to ones I've done dozens of times, so I can seem to know what I'm talking about and still bring some value with low effort. 

Anyway, I'm not sure there's a message or a point to this post, I manly wanted to say hi again, and tell I'll be back to writing here. At least until I pick up the habit again,  I don't expect to write more than one blog a month (you'd be amazed how much time it takes me to write the same post in a 2nd language), but I'll try to keep at least to this pace.

Pay to stay?

So, I stumbled upon (or rather,  saw it in Alan Page's five for friday) this blog post explaining why companies should "pay their people to stay" that is - offer the people who are already working and having good impact on the company a competitive salary. I read the argument there, and it's convincing at first glance, at least up until the point you start thinking about it. For those who don't want to read the entire post, I'll sum it up - People currently working for the company are becoming more valuable as they stay, since they gain domain knowledge and become more effective in the specific thing the company does. Therefore, the argument goes, it's worth paying those individuals above market value for those skills.

So, what's wrong in this argument? Oh so many things. 

First of all, the assumption that if you pay well people won't leave is not realistic. People leave for a lot of different reasons - they might look for a position that is not available, they might move to live elsewhere, or even just feel that they want to change domain or learn a new area of technology. That's assuming they don't run away from a bad boss.  So, let's just put this on the table. You might be paying well, only to retain 10% of the people you want (or it might be 90%, but I doubt it). 

Second, let's assume this strategy works - if we're doing it, other will too. In this case, let's look on the options our star employee with 5 years of tenure. Before we implemented the suggested change, their salary would get a nice 20% bump if they would be hired for their current level. Now, we've implemented a tenure-based salary increase that compensates for that, and their salary is 10% above market. They interviewed with foo-corp, which finds them a perfect match for what they are looking for. They can keep on looking, knowing that many other suitable candidates might have the same conditions, or they can offer above market rates, resulting in the market value of the job rising and our formula will need to be updated. Since companies do have some limits on their budget, this race to the impossible salary will stop somewhere, and on the way might have other side effects (such as "no raises for the first three years" or just underpaying juniors and deepening the imbalance between higher and lower paid workers). Another possible side effect if such practices are common, people might be hesitant to interview people who have been in their current workplace for over 5 years, pushing people who care about their career to start looking sooner just to avoid being labeled this way if they do need to change jobs in the future. 

So, the financial model is not really convincing. But let's assume for the sake of the argument that it does, that we've found a magic formula that actually helps retaining people in significant numbers in a financially reasonable way. Do we actually want this? The post assumes that tenured people are more valuable, but that's far from being universally true. There are several costs to having people, even good ones, stay. Here are some disadvantages:

• Reducing our bus factor. If we nurture those super-valuable people and they stay forever, they become more and more central to our organization, despite honest attempts they will gather more knowledge and expertise, and more people will rely on them, when they finally leave, or retire, it will be ten times more painful than if they left after only five years. 
• They prevent change. The people who are being retained are central to the current way of working. The learn the organization and grow accustomed to it. When they say "we've always done it this way", or "we've tried it and it didn't work" it will carry even more gravitas. 
• Less mobility means less ideas travel in the industry - yes, we might meet in conventions and meetups, but nothing can compare to working in a different setting and seeing your previous ideas about what's right just burn to the ground in a new context.
• Slower growth to the others: When people who are central to the organization leave, there's some sort of vacuum left behind them in all the things they were just the go-to person. When they leave, this vacuum is filled by one or more people, who now need to fill boots bigger than they wore before, and most of the time they grow to do this well, and give it their own spin. Thus the industry gains more skilled people, the company gets to have the same tasks benefit from multiple viewpoints and the people themselves are gaining skills and sometimes a promotion. Yes, there are growing pains, and the right person leaving in the wrong time might mean those pains can topple a company, but by having multiple, smaller, holes to fill, we avoid the giant crater.  

One final point - I'm not advocating to push your senior people out (I keep this recommendation to cases where you're starting to think "Uh, oh - if this person leaves we're all doomed"). If you're able to create a workplace that has a good balance between compensation, culture and professional interest people will stay and you will benefit from that extra amount of domain knowledge they learn, knowing that other companies will have a hard time matching you on such a fine balance. But don't fret if they leave. The graveyards, after all, are filled with people who couldn't be replaced.

Wiring the winning organization - Book review

                                

 

Or, in its full name: Wring the Winning Organization: Liberating Our Collective greatness through Slowification, Simplification and Amplification. By Gene Kim and Steven J. Spear.

It's a bit of a mouthful, but this matches perfectly the ambition of the book's authors: To devise a theory of everything. Or, at least, of business operational success - any business. Naturally, in order to do that, they are abstracting quite a bit, but despite everything they manage to create something that sounds convincing and powerful. It's a great book, but it suffers from a major drawback for me - it's a managers oriented book, which fits their theory (short version - it's all about management) but is not as actionable for me as I would like it to be. I can still use the insights from it to reason with my  managers, and to set some goals I will want to advocate for, but it puts one heck of a nail in the coffin of "driving a change bottom-up" idea.

So, to the theory of everything. 

The authors define 3 layers of "stuff" that happens in just about any business:

Layer one: "Technical Object". Or, in other words, the doing. This is what the skilled people are doing - be it coding, chiseling a piece of rock or selling timeshares to elderly people.

Layer two: The tools. Those are the tools used to do the things in layer one, the hammers and jigsaws, the build systems and expensive electronic microscope.

Layer three: The social circuitry. This is how your organization is structured, how data flows, how dependencies are managed and how decisions are being made.

The radical claim the authors make is that while there are a lot of differences between organizations in their layers 1&2 needs, in layer 3 it's pretty much all the same. Therefore, it stands to reason that in this layer, good practices can be transferred between industries, which we can see happening  in some places (the one I remember is the Toyota manufacturing approach being an inspiration to devops movement in software development). The book's main message is that in order to increase productivity & quality while decreasing costs and making employees happy and motivated, you "only" need to do three things. They name them "slowification, simplification & amplification". Do those, and you're on the right path. Note - there's a distinction between "simple" and "easy". Each of these words is packing a whole lot of work within it.

The first term is a word they made up to carry the meaning they were looking for of "slowing down to make things better" (they say that in German there is "Verbesserung", which my limited knowledge just says means "improve", but I might miss some context).  The idea is that since when under pressure we revert to our habits and instincts instead of thinking (in Daniel Kahnman's terms that would be "system 1(fast) thinking"), we need to slow down to engage our brains (system 2, or "slow" thinking). This can happen at many levels - some phases, such as planning\design are slow by nature, and might only need some small nudges to be more conscious, we can use a testing environment that is low-risk and we can control to a greater degree, and we can find ways to slow even the performance environment (that's the name they use for "production", as it's more broadly applicable). Let's take for example a basketball game - before a game, the coach might go over some tactics with the team, draw some sketches on the board, so that players won't have to communicate the plan while they are running after the ball. This way they have time to suggest adjustments and deliberate alternatives.  Then, when in practice, they might stop everything to perfect the way they pass the ball around, and during the game, a player can take a couple of seconds dribbling to re-orient and plan the next move. Slowing down is not always possible - a player jumping for the rebound ball can't pause to think, so in this instance they will have to rely on the instincts they've built during practice.

Simplification, thankfully, retains its dictionary meaning. in order to succeed, we want to solve easier problems. They mention three techniques to achieve this: Modularization is the way we partition a large problem to smaller yet coherent problems. Incrementalization is their way of saying "baby steps", where we establish some solid known basis (through standards, automation, documentation and so on), and invest efforts in learning the next new thing and linearization is creating a sequence where actions are depending at one another.

Most of the book is alternating between explaining the three concepts (or is it principles?) and analyzing success and failure examples according to them. They show, for instance, how the Wright brothers were able to get an airplane flying in a fraction of the cost of the (failing) competition because instead of trying to build one complete plane after another, they did a lot of experiments on various parts such as testing only the wing design elevation power, without attaching it to an actual plane, or using a kite in order to test the ability to steer by curving the wings. Those examples make a pretty good case for the main theory, but the one thing that was probably the reason for the book being that convincing was the opening "vignette" which is available in google books for free (link, I hope), they do a much better job of describing it than I could, but the main idea is describing how poor management and social circuitry are making a mess of something relatively simple such as managing moving furniture out of hotel rooms and painting them.
In between all of those, there are a few insights that are worth mentioning, such as the realization that the social circuitry should match the way the technical layers are organized (which, if we think about it, is a take on Conway's law that reverses the causal direction. It's not that "since our org structure is X, all of our systems will be X compatible", but rather "since we want to produce X, we need to structure our org in a manner that will support it"), or a motivational explanation of why the framework presented in the book works (in short: simpler, more isolated problems enables more minds to engage with the problems at hand). The most depressing insight they share, which I have already mentioned, is that those things don't come bottom-up, to really have an impact, one must have executive power. I'm guessing that as an individual, I can use some of these ideas to structure the work around me to some limited extent, but the truth is - simplifying most of the problems I deal with will require change in multiple other teams, so I can nudge, convince, and haggle - but I can't really control what's going over there, so my effect will be limited.

So, all in all - great book, especially if you're somewhere in the C-suite. I wonder if it should be taught in management courses.

I have released an open source library

 עברית

In my past two jobs we always talked about collecting some tests metadata to analyze later, but never had time to collect it. Well, I had a few moments between jobs to create an easy to extend (I hope) library for pytest. It might or might not help me in future workplace, but I'm hoping it will help someone. 

Taking the perspective of building a library for unknown users was an interesting experience - I obviously needed to put more emphasis on documentation, but more importantly, I needed to think "how can a user customize this for their needs?" One result is that I chose to omit functionality - for instance, I'm not providing a database storage utility, but leaving that for the user who knows which DB and schema are they using. I still consider creating an example project using this library, but we'll see if I have time and attention for that. 

Anyway, its free to use, modify and so on. If you need help, ping me (or better - open an issue)

PyPi: https://pypi.org/project/pytest-stats/ 

Github: https://github.com/amitwer/pytest-stats