457 Tech Debt with Gidon from Redis

רברס עם פלטפורמה

[קישור לקובץ mp3]

פרק מספר 457 של רברס עם פלטפורמה - הוקלט ב-2 במאי 2023.

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

Technical debt, image by Midjourney

00:58 גדעון ו-Redis

(רן) אז לפני שנצלול לשם - כמה מילים עליך, גדעון?

• (גדעון) בן 48, גר בתל אביב, יש לי שני ילדים
• אני בתחום הזה עשרים-וכמה שנים, לא נדייק את זה . . . .
• במקור, קיבלתי את המקצוע בממר”ם, אחר כך . . .

(אורי) בתחום החובות הטכניים? . . . אתה גובה?

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

(רן) כמה זמן אתה ב-Redis, בעצם?

• (גדעון) אני ארבע-וקצת שנים ב-Redis.

(רן) אוקיי . . . כמה מילים על Redis?

• (גדעון) אז אני חושב - אני מאמין - שרוב המאזינים שמעו על Redis
• אז אנחנו בחברה בעצם מקדמים את Redis כ-Cache וכ-Database
• ויש לנו גם את ה-Open Source Redis, שזה מה שרוב האנשים מכירים
• וגם את Redis Enterprise, שזו בעצם הגרסה ה-Enterprise-ית - אקסטרה יכולות, אקסטרה אמינות, אקסטרה Availability . . . זה הנדבך השני.

(רן) כן, אז בגדול זו חברה שמייצרת Hardcore Infrastructure, דאטאבייסים . . .

• (גדעון) זה העולם שאני אוהב, כן.

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

• (גדעון) בחברה יש 800-וקצת אנשים, לא זוכר את המספר בדיוק,
• והפיתוח - אנחנו 200 איש, שזה נגיד 80-90% מזה זה מפתחים, אז 180 . . .

(רן) אוקיי . . . .

(אורי) והרוב עובדים על המוצר Enterprise? או . . .

• (גדעון) הרוב המכריע עובדים . . . ה-R&D אצלו מחולק ל-Core ו-Cloud
• כשבעצם ה-Core - שזה החצי שלי של ה-R&D - הוא בעצם בונה מוצר שהוא גם Deployed ב-Cloud שלנו
• וגם יש לנו שת”פים עם Microsoft ו-Google, אז גם שם
• ויש גם ללקוחות On-Prem וגם ללקוחות Kubernetes . . . .
• אז זה ה-Core, והוא הולך לכל המקומות.
• וחוץ מזה יש לנו את ה-Cloud unit, שבעצם עושה את כל ה-Deployment של הדבר הזה בענן.

(אורי) אוקיי.

03:13 “תייבש Tech-Debt מספיק זמן - והוא הופך ל-Roadmap item”

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

וזהו, והקונפליקט הזה קיים, אני מניח, בהרבה מאוד חברות.

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

• (גדעון) אז קודם כל, אני חושב שהוא תמיד קיים - ואני חושב שאם הוא לא קיים אז זו בעיה, אז הוא צריך להיות קיים, כדי לאזן את האינטרסים האלה.
• הוא מופיע כל הזמן, ואני חושב שאם הוא . . . הוא לא חייב להיות Manifested כקונפליקט - זה כזה “משיכת חבל”, משני הכיוונים.
• אני מנסה לחשוב על איזה סיפור ככה דרמטי לגבי קונפליקט . . . אני יכול להגיד שהרבה פעמים מייבשים . . . ה-Product “מייבשים” כל מיני פרויקטים ב-R&D, ובדרך כלל יש לזה . . . .
• זאת אומרת, תייבש Tech-Debt מספיק זמן - והוא הופך ל-Roadmap item . . .
• הוא יהפוך למשהו שאתה חייב לעשות - וחייב לעשות אותו דחוף.
• היה לנו סיפור כזה לאחרונה, לא רציתי להתחיל עם הסיפור הזה, אבל. . .

(רן) אפשר להתחיל עם משהו אחר . . .

(אורי) יאללה . . . המאזינים שלנו כבר לא יכולים לחכות . . . .

• (גדעון) לא, לא, זה דווקא סיפור טוב - אני מאוד גאה בצוות שלי על מה שהוא עושה שם, אבל . . .
• אז היה לנו - יש לנו - מוצר, יש לנו מוצר שה-Control Plain שלו כתוב ב-Python.
• הוא נכתב במקור ב-Python 2.0 - המוצר קיים כבר 10+ שנים.
• ואמרנו כל הזמן “צריך לעבור ל-3.0 - שתיים, מתישהו יהיה End of Life”
• ו-”שתיים - שבוע הבא End of Life” ו-”שתיים שבוע שעבר ה-End of Life” ו-”לפני שנתיים ה-End of Life” . . . . - ועדיין לא עברנו ל-Python 3.
• וככל שהזמן עובר, המחיר נהיה יותר גדול - המחיר של לנהל מוצר ב-Python 2.0 נהיה יותר גדול
• ולכן גם הפרויקט נהיה יותר ויותר גדול, ויותר ויותר דרמטי, ולכן אף אחד לא רוצה . . .
• המחיר שצריך לשלם פה - הוא ניהיה יותר ויותר גדול.
• ואז בסוף, מגיעים לקוחות ואומרים “אנחנו חייבים את הדבר הזה . . . אנחנו לא מוכנים לקנות מכם מוצר, אתם עובדים עם טכנולוגיה מיושנת שהיא End of Life עם Security Vulnerabilities - צריך להיפטר מהדבר הזה”.
• ואז זה ניהיה מצב חירום וזה כבר לא Tech Debt - זה עכשיו דרמה גדולה עם Deadlines משוגעים . . .

(רן) זה Gatekeeper ל-Sales, זה הופך ל-Business Value משמעותי . . .

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

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

(אורי) נכון, אבל אותם צוותי Compliance, Security . . . הם יגידו “אה, אני לא יכול לקנות את זה”, ואז זה ירים אצל האיש מכירות את הדגל.

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

(אורי) נכון

• (גדעון) אני חושב . . . כשבאתי וחשבתי על מה אני הולך לדבר פה, אז אמרתי “איזה סיפור Tech Debt טוב יש?”
• ואז אמרתי, הסיפור Tech Debt הכי טוב הוא זה שלא מספרים אותו, כי טיפלת בו בשוטף כל הזמן
• ואף פעם לא הגעת למצב שאתה צריך לשפץ את הבית, כי אתה כל הזמן מתקן תיקונים קטנים.
• וזה בדיוק הסיפור, זה כזה “סיפור להפחיד את הילדים”.

(אורי) תיאוריית החלונות השבורים וכל מיני כאלה . . .

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

(אורי) זאת נקודה חשובה. כאילו, לפעמים לא מתמודדים עם Tech Debt, כי יש מה שנקרא, Hero Culture, אוקיי?

• (גדעון) לגמרי.

(אורי) “אנחנו ניתן למערכת להישבר - וכשהיא תישבר, אנחנו נעשה את הבלתי יאומן!”

• (גדעון) נכון, וזה, אני חושב שזה מאוד . . . אני לא יודע, כי לא הייתי בתעשייה אחרת, אבל אני מרגיש שזה מאוד משהו בתעשייה הישראלית שהיא מאוד Startup-Oriented
• וזה מאוד חשיבה של Startup בעיניי.
• חשיבה כזאת של “הקומנדו שיכנס ויעשה את הדבר ברגע האחרון”
• וכמו שאתה אומר - להיות גיבור
• אבל זה מגיע . . . זאת אומרת, המחיר של זה לארגון, אם נסתכל על זה, זה היה מחיר גדול.

(אורי) נכון.

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

08:20 מי מכם עובד עם Netscape?

(אורי) הצד השני של זה, לפעמים, כשה-Tech-Debt נוצר כ”בור” מאוד רציני, זה מה שנקרא ה-Netscape Phenomena. מי מכם עובד עם Netscape?

(רן) אני מכיר מישהו . . . .

(אורי) כאילו, אף אחד לא עובד עם Netscape, כי מישהו החליט שצריך לעשות Refactoring לכל ה . . .

• (גדעון) “זוועות ה-Refactor”, מה שנקרא . . . .

(אורי) או ה-Rewrite . . . .

(רן) כן, יש בלוג-פוסט מפורסם של Sapolsky על ה . . .

• (גדעון) איזה?

(רן) אני לא זוכר את הכותרת [Things You Should Never Do, Part I, כמה הולם . . . .], אבל בגדול הוא בא ואומר שה-Rewrite - “ה-Rewrite הקטלני” - והוא נותן כמה דוגמאות. יכול להיות שאחת מהדוגמאות זה ב-Excel [יותר Quattro Pro זצ”ל], שזו קבוצת-מוצר שבה הוא עבד, אבל יכול להיות שגם על Netscape [גם כן], אני לא זוכר [זוכר נכון].

• (גדעון) אני עבדתי בחברה ש-Rewrite של המוצר הרג את אותה החברה . . .

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

• (גדעון) תראה, אני חושב שאני לא מת על השם Tech-Debt,
• והסיבה שאני לא מת על השם הזה זה כי קודם כל זה מכוון למשהו שהוא יחסית-צר, בעיניי.
• ולא כל דבר שאתה רוצה לקדם כארגון R&D, הוא נכנס לקטגוריה הזאת.
• אני חושב שהדבר המרכזי פה, זה להגיד מה “ה-Call שלנו”, מה הפרספקטיבה שלנו כ-R&D - וזה ה-Tech-Debt.
• זאת אומרת, אני חושב שארגון שבונה מוצר בצורה בריאה, צריך להבין שמה שיש ל-R&D להגיד הוא חשוב ורלוונטי,
• וזה לא רק . . . זאת אומרת, מאוד קל ליפול למקום הזה של “ה-Product - תגידו מה עושים?”
• “אתה רוצה לעשות Tech-Debt? תשכנע אותי שזה נותן לי Value, אז אני - אנחנו - נעשה את זה”.
• עכשיו, צריך לשכנע, חד-משמעית צריך לשכנע וצריך להוכיח את ה-Value
• אבל אני חושב שלפני הכל, צריך ליצור את האמון הזה, של “יש לי מה להגיד וכדאי שתשמעו את זה”
• כי אף אחד לא . . . אף אחד אחר בארגון לא רואה את הדברים ש-R&D רואים
• כמו כל חלק בארגון, כן? - אני לא חושב שאנחנו מיוחדים, אבל חשוב להביא את הדבר הזה לידי ביטוי.
• ויש לי כן סיפור חיובי על דבר כזה - שאני בורכתי בארגון Product שאני מאוד אוהב לעבוד איתו ושיש לנו באמת . . .
• החשיבות שהם נותנים לאמון איתנו היא אותה חשיבות שאנחנו נותנים - וזה כיף לעבוד ככה.
• אז כשבאנו ואמרנו “יש לנו פה אזור, יש לנו פה צוות, אחד הצוותים הכי רועשים בחברה, צוות ה-Cluster - נורא רועש, מלא אקשן, מלא Priorities, מלא . . . “
• כל הזמן קונפליקטים על מה מכניסים, ומאוד קל ליפול למקום הזה של “אין עכשיו זמן”.
• מה זה קל? עשינו את זה במשך כמה שנים . . .

(רן) זאת אומרת, זה צוות שתפקידו הוא לנהל Cluster של Redis Servers, עם הלוגיקה המורכבת של איך עושים Sharding . . .

• (גדעון) כן, זה שם Distributed Logic . . .

(רן) איך מנהלים Failover ו-Sharding ודברים כאלה . . .

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

(אורי) תן לי לנחש - זה גם מין צוות כזה, שכמעט כל Feature שתעשה, אז יש משהו שהוא צריך לעשות, נכון?

• (גדעון) נכון מאוד.

(אורי) זה “צוותי-צומת” . . .

• (גדעון) בדיוק, בדיוק.
• זה ועוד צוות אחר הם שני הצוותים שאפשר להגיד שכל ה-R&D שלנו צמח ממנו
• וזה בדיוק איך שתיארת את זה.
• אז בתוך המקום הזה, זה צוות שלאט לאט הגענו למצב . . .
• צוות סופר-מקצועי, אנשים . . . באמת אחד הצוותים הכי חזקים שיצא לי לראות
• ועדיין - קוד נשבר כל הזמן ו-Feature-ים מסתבכים ואתה אומר “ה-Feature הזה ייקח שבועיים” ופתאום הוא לוקח חודשיים
• והייתה שם איזשהי בעיית Quality . . . .

(רן) משהו שם מסריח . . .

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

(אורי) אתה עוצר אותו - אתה עוצר את הכל.

• (גדעון) כן, אבל עצרנו . . .
• מה זה עצרנו? לא עצרנו, אלא הורדנו נתח יפה מה-Backlog של הצוות הזה . . .

(אורי) עבור ה-Tech-Debt . . .

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

13:22 מה עושים עם זה?

(רן) אבל יצרתם להם איזשהו “מרווח נשימה”, שבו הם יכולים לעבוד על ה-Tech-Debt - שדרך אגב, אמרת שאתה לא אוהב את השם, אז תכף נחזור גם לזה . . .

אבל אוקיי, אז יצרתם להם איזשהו מרווח נשימה - ומה הם עושים עם זה?

• (גדעון) אז הם השקיעו קודם כל בכתיבת תשתיות ל-Testing וסביבת CI חדשה
• ובעצם באו . . . אנחנו מכוונים יותר לכיוון של CI, שתיהיה הרבה יותר אוטונומיה לצוות
• לפני זה היינו ב-Mode של CI כזה “גלובלי”, של כולם
• שזה מאוד עובד כשיש לך 20 מפתחים ולא כשיש לך 100 מפתחים . . . .
• ואז, ברגע שיצרנו את ה-CI, איזשהו “פר-צוות”, זאת אומרת - זה בעצם היה המדד שלהם
• “צרו לעצמכם CI, ותבנו אותו בצורה שמשרתת אתכם”.
• אני חושב שזה דבר מאוד מאוד מרכזי, לחבר את הכאבים שהם חווים מתהליך הפיתוח שלהם, ליכולת שלהם לפתור את זה
• לפני זה היינו מאוד ב-Mode של לפני עשר שנים הייתי אומר, של צוותי Quality שבודקים אותם וצריך לדבר איתם וצריך לעשות איתם מו”מ
• “יש לי בעיה פה בזה, תסדר לי את ה-Test”
• וחלוקת ה-Ownership הזאת לא עוזרת . . . .
• אז זה בעצם היה מה שהם עשו - והשקיעו בזה כמה חודשים, אבל לא Full time, אלא תוך כדי עבודה על Feature-ים אחרים . . .

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

• (גדעון) כן, כן, הרבה מאוד כתיבת Test-ים . . .

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

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

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

(רן) Fatalism . . . “יהיה מה שיהיה” . . .

15:28 יחס חוב-מוצר

(אורי) יש אספקט מאוד חשוב על Quality ו-Tech Debt ודברים כאלה, שבא ביחד עם ערך של Ownership - פעם שזה הקוד שלי, בסדר? הוא שלי, אני בודק אותו, אני “שם עליו את הסטמפה”, אני מתעורר בלילה כשהוא נופל . . . .

ה-Tech Debt מקבל עוד יותר חשיבות - וגם, אתה יודע, גם ביחסים עם קבוצות-מוצר וכאלה . . .

אנחנו פשוט אמרנו ל-Owner-ים - ”יש לכם 20% מהזמן לטפל ב-Tech Debt שלכם והחבר'ה מהמוצר יודעים את זה . . . .”

• (גדעון) אז . . .

(אורי) אז 20% זה . . . לא יחס חוב-תוצר, יחס חוב-מוצר של . . . וה-Owner מנהל את זה, הוא מנהל את ה-20% האלה שלו.

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

(אורי) והקוד הוא פחות Legacy ופחות תלויות . . .

• (גדעון) כן, אז אנחנו משחקים עם הכמויות
• אני, אגב, בזמן השירות שלי ב-Redis, עברתי מהפך בהסתכלות שלי על השיטה הזאת של - אני קורא לזה ”שיטת ה-Bucket-ים”
• לא יודע למה, כן . . . יש לך את “הדלי” הזה של ה-Tech Debt
• כי בסופו של דבר, באתי מאיזו תפיסה כזאת של “Show me the Value”, כן . . .
• של בסוף כאילו, אם יש לך את ה-Tech Debt שלך, אתה רוצה להחליף את גרסת ה-Python שלך - אז בוא תסביר לי למה זה טוב, אם זה טוב, אנחנו נסקג'ל את זה [Schedule it] - נשמע מאוד הגיוני בסך הכול.

(אורי) זה מאוד ריכוזי, לעומת זאת . . .

• (גדעון) אז א’ - זה ריכוזי
• ב' - זה מאוד מאוד תלוי-פרסונות
• זאת אומרת שאם יש לי עכשיו, בצוות מסוים, יש לי מנהל חלש ואיש Product חזק - אז הוא ירמוס אותו.
• אגב, הרבה פעמים אני רואה תופעה הפוכה
• ואני יכול להגיד על עצמי, בתור מנהל צעיר, שאני הייתי לגמרי כזה, הייתי מאוד Execution-Oriented ומאוד “רגע, יש Deadline! לקוחות על הראש לי! חבר'ה, חכו עם ה-Tech-Debt עכשיו”
• “אנחנו נחכה חודשיים ואנחנו נעיף את ה-Feature”
• ופתאום, אתה מסתכל אחרי שנה ואתה אומר, כמעט לא עשיתי “Tech-Debt”.
• אז אני חושב שא’ - יש עניין של מי האנשים ומי הפרסונות
• ויש גם עניין של למנוע חיכוכים, זאת אומרת - אני רואה את זה, לא יודע, המשל שעולה לי כרגע בראש זה הסכם על ילדים בגירושים . . . לא יודע אם אתם מכירים את הדברים או לא, אני מכיר.
• ההסכם הזה הוא בסיס לעבודה, זאת אומרת, זה לא שעכשיו אנחנו . . .
• זה 20% “ברזל” . . .
• יש לי עכשיו צוות אחר, שיש לו בעיה בתשתית ה-Network שם, ושכנעתי את ה-Product שחצי מהזמן של הצוות נופל הדבר הזה
• למרות שצוות עושה בדרך כלל 20% Tech-Debt
• כי שכנענו את ה-Product והם הבינו והם פתוחים לדבר הזה - כי גם קורה הדבר ההפוך: יש עכשיו לחץ, אנחנו נוריד את ה-Tech-Debt ונדלבר [Deliver].
• אז זה בעיניי בסיס - השיטה הזאת - אבל היא, אם אתה ננעל עליה, אז זה נהיה מאוד מאוד . . .
• זאת אומרת, צריך להיות שכמו שאני רוצה שה-Product יסבירו לי מה זה ה-Feature-ים שאני בונה
• גם אם “אוקיי, החלטתם וזה העניין שלכם ואתם קובעים מה אנחנו בונים - אני רוצה להבין ואולי יהיה לי מה להגיד על זה
• אז זה אותו הדבר ב-Tech-Debt - אני צריך לדבר איתם, לספר להם ואולי יהיה להם מה להגיד לי על זה, אז . . .

18:57 איך אתה יודע?

(אורי) אז איך אתה יודע באמת, שאין לך צוות שעכשיו לא עושה Tech-Debt, הוא מייבש את ה . . .

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

(רן) אבל זה איזושהי “רוח המפקד” - כאילו, אתה בא ואומר “זה חשוב לי, תעבדו על זה”.

(אורי) כן, אבל אתה יודע אם הם באמת עשו את זה?

• (גדעון) אז כן, אנחנו מודדים את זה
• אנחנו מקטלגים כל Ticket לאחד מ . . .
• יש לנו שלושה Bucket-ים - Feature-ים ו-Maintenance ו-Technical Debt
• וכן - אני חושב שזה באמת מאוד חשוב, כאילו, להראות את ה . . .
• יש כאלה סיסמאות, שאומרים - אבל אם לא עושים איזושהי פעולה, אז אנשים לא טיפשים, הם מבינים שזו סתם סיסמא . . .

(רן) “ימי חופש ללא הגבלה!” . . .

• (גדעון) לדוגמא . . .

20:09 חובות מכל מיני סוגים

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

• (גדעון) כן, תראה - אז ההגדרה הקלאסית של Tech-Debt זה כאילו “כתבתי, עשיתי, עבדתי על פיצ'ר - קיצרתי את הדרך בכל מיני דרכים, “הלוויתי מעצמי-מהעתיד” - והחוב שלי זה לתקן את הדברים הלא-מושלמים שעשיתי”.
• עכשיו, יש הרבה מזה, אין ספק, אבל א' - אני חושב שזו ההגדרה לא הכי ברורה
• זאת אומרת, לדוגמא אז הדוגמא שנתתי קודם, שיפורי Testing - זה Technical Debt? זה לא Technical Debt?
• מכיוון שהיו לי הרבה ויכוחים בתוך החברה, אם לקרוא לזה ככה או לא, אז אני מוצא שהוויכוח הזה הוא לא מאוד מועיל, לא מאוד מעניין . . .
• זאת אומרת, לפעמים אני מקדם דברים שאני מגדיר אותם כ-Technical-Debt, שהם שינויים באיך שהמוצר מתנהג, שהם לא Technical Debt, הם שימושיים למוצר.

(אורי) זה Product-Debt . . .

• (גדעון) בדיוק, “Product-Debt”
• ואני עושה את זה מיוזמתי . . . Product מאוד שמחים, אין להם מקום לעשות את זה . . .
• ואני מסתכל ואני אומר, מכל מיני שיקולים - של המוצר, של החברה, של האנשים שלי - שאני רוצה לקדם את הדבר הזה
• ולכן אני חושב שנורא להתעקש על ההגדרה הזאת.
• הייתה לי תקופה שהיינו מאוד מאוד מתווכחים:
• “אני רוצה את ה-Feature הזה!”, “לא, זה Technical Debt - ‘תנגן’ את זה מה-Budget שלך!” . . .
• “אוקיי, אז אני . . . אתם יודעים מה? אז אני לא אנגן את זה, כי זה Technical Debt וזה . . . !it's my choice,”
• “לא, לא, אנחנו רוצים שתעשה את זה” . . .
• כי זה לא מועיל, הדבר הזה . . .
• בסוף, אנחנו צריכים - למרות שאמרתי שאני לא אוהב את הדבר הזה של “בואו נדבר על ה-Value”, חייבים לדבר על ה-Value
• פשוט צריך לתת Guidelines לצוותים עצמם, איך עובדים
• אבל בסוף צריך להיות דיבור והסכמה עם ה-Product.

(רן) אוקיי, אבל מה עוד יש שם?

• (גדעון) מה הדברים שהם . . .

(רן) לא, אז הדברים שהם כן עבודה שצריך לעשות שהיא לא המוצר, אבל היא גם לא Technical Debt, זאת אומרת - יש פה Bucket נוסף?

• (גדעון) אז יש Product Debt, שאצלנו יש לא מעט מזה
• כאילו, החלטות שעשינו בעיניים פתוחות לפני חמש שנים או יותר, ואנחנו רוצים לסגור אותן.
• יש לנו יצירה של Testing Types חדשים
• שזה מאוד הפוקוס שלי כרגע - אנחנו רוצים לעבור למציאות חדשה.
• יש כל מיני דברים . . . כן, האמת שאפשר לקרוא לזה עדיין Technical Debt “קלאסי”, כן . . .
• תיעוד, שיפור תהליכים, לזרז את ה-Build - כל מיני דברים כאלה, שמשפרים את החיים של המפתח, הם לאו דווקא בדיוק Technical Debt.

(אורי) כמה . . . . מפתח בא לעשות שינוי בחתיכת קוד, מסתכל על הקוד - חוטף כאב בטן . . . . זה Tech-Debt או לא Tech-Debt?

• (גדעון) זו נקודה מאוד מעניינת, כי אני אגיד דבר והיפוכו . . . .
• מצד אחד, אני מאוד מאמין שאסתטיקה, למפתח - אני חושב שיש את זה בכל מקצוע אבל אני מבין את המקצוע הזה -
• אני חושב שיש איזו תפיסה של אסתטיקה, שאתה, כמו שאתה אומר, “מתהפכת לי הבטן, מה זה הגועל הנפש הזה?!” - אם זה משפט ששומעים ממפתח אז זה דבר שצריך להתייחס לאינסטינקט הזה, זה דבר אמיתי וחשוב.
• אבל אני חושב שזה דבר אמיתי וחשוב בשביל להתחיל שיחה.
• אחר כך, אתה צריך להגיד לי - אוקי, זה מגיעיל אותך איך שזה כתוב? אתה רוצה לעשות Re-write למודול הזה? תסביר לי מה אני מרוויח מזה, תסביר לי למה זה יותר חשוב מהדבר ההוא . . .
• זאת אומרת, אני חושב שאנחנו כ-R&D צריכים לתעדף את ה-Tech-Debt, כמו Roadmap של מוצר.
• כי יש לי הרבה אזורים שכבר חמש שנים אומרים לי “וואו, אנחנו חייבים לעשות פה Re-write!”
• אוקיי, בסדר, חייבים לעשות Re-write - אבל יותר חשוב שנעשה את ה-Tech-Debt ההוא . . .
• זה לא בהכרח אומר שצריך לעזוב הכל ולנקות את זה רק כי זה עושה לו הרגשה רעה . . .

23:57 איך מודדים Tech-Debt?

(אורי) פעם קראתי איזשהו מאמר, ששאל את עצמו “איך מודדים Tech-Debt?”

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

אוקיי, הוא סיים לכתוב . . . .

• (גדעון) לא, צריך לשאול אותו אחרי חודשיים, לדעתי . . .

(אורי) הוא סיים לכתוב איזשהו Feature - איך אתה מרגיש עכשיו עם הקוד? . . . .

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

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

ואז מגיעה נקודת ה-Re-Write הזאת, שכנראה צריך לעשות משהו גדול יותר - אבל בסוף, הציר ה-Y של הדבר הזה, זה . . .

(רן) אתה מתאר פה את התמרת פורייה, אורי . . . יש פה שני גלים, יש פה שני גלים עם תדירויות שונות . . .

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

(רן) כן, אבל זו גם בעיה, זאת אומרת - אחד המדדים זה עד כמה מהר בנאדם יכול להיכנס ל-Code-base . . .

• (גדעון) כן, אבל לא כל דבר שדוחה את המפתח חדש הוא ענייני . . .

(רן) נכון, נכון . . .

• (גדעון) . . . . זה כאילו, זה משהו שצריך . . .

(רן) . . . אבל זה Signal, זה Smell, אוקיי?

• (גדעון) כן, כן, נכון . . .

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

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

לעומת זאת, יש מה שנקרא “מורכבות מקרית”, אני חושב, Incidental - וזו מורכבות שקרתה “בטעות”, אוקיי? כתבת קוד לא נכון, לא תיעדת, לא עשית חלוקה נכונה בין המודולים, היית יכול לעשות את זה יותר פשוט . . . .

אז זאת אומרת, כאילו - דיברת על מה המדדים ל-Technical Debt, אז אחד מהמדדים לטעמי, גם צריך לכלול את “כמה זמן לוקח למפתח חדש להיות פרודקטיבי בתוך המוצר?” . . .

• (גדעון) האמת שאני אוהב את ההגדרה הזאת, כי יש לי בדיוק . . . .
• הצוות עם ה-Network Refactoring - אני חושב שיש שם אלמנטים באמת של קוד שמאוד מאוד קשה לגשת אליו.
• אבל אני חושב שצריך להסתכל על זה גם Top-Down וגם Bottom-Up
• זאת אומרת, כשאני מסתכל, אני רואה אזורים מאוד מאוד גדולים שאני אומר “אוקיי, יש פה חסר” או “יש פה משהו שלא נגענו בה הרבה שנים”
• יש יותר מקום להסתכלות הזאת במוצר שקיים עשר שנים וצברנו בו לא מעט חובות.
• אבל מאוד מאוד חשוב לקבל את ה-Input הזה מלמטה
• גם כי אנשים רואים, גם כי אתה רוצה אותם מחוברים - אתה רוצה את “היוזמתיות” הזאת
• וגם השינויים הקטנים האלה שהם עושים - ה-Smells הקטנים האלה - זה לא מאוד מדיד בעיני, או לפחות לא מצאתי את הדרך, אבל אני באמת חושב שזה, אפילו אם זה רק שימח את המפתח, יש לזה Value, זה לא חייב להיות מאוד מדיד.

(רן) א’ - אני חושב ששמחה זה מדד חשוב אצל המפתחים [okify! ד”ש מ-399 Bumpers 70], אבל אני מסכים איתך שיש אתגר משמעותי בלמדוד - הרבה דברים בפיתוח, לא רק את זה, אבל גם את זה.

27:43 מנגנון בר-קיימא

(רן) אבל בוא רגע נחזור לאיך אפשר לייצר מנגנון שהוא ססטיינבילי (Sustainable) - שמשמר את ה-Tech-Debt ברמה “הנכונה”. דיברת מקודם על 20%, על 10%, דיברת על מקרה שבו אולי הייתה הזנחה ואז כבר ה-Product היה צריך שתתקנו את זה . . . . וזה בטוח קורה בכל חברה, אני חושב שכל אחד יכול להזדהות עם מקרים כאלה.

אבל בואו רגע נדבר על גישות לתחזק Technical Debt בצורה Sustainable-ית - אז אחד הזכרתם, נגיד שתיים: אחד זה להקצות איזשהו אחוז של זמן, אוקיי?

יש גישה אחרת, שהיא קצת יותר דינאמית, שבה יש משהו שנקרא Error Budget - גוגל פרסמו את זה בספר SRE שלהם, שבו הם אמרו “אוקיי, נכון יש איזשהו נגיד, 5-10% שבהם מטפלים, אבל אם נגיד ה-Service או אם הקומפוננטה (Component) שאתה עובד עליה מפשלת על ימין ועל שמאל - אז אתה צריך להשקיע 50% מהזמן, אוקיי? אבל המדד הוא סובייקטיבי - זה לא שאתה מסתכל ואתה אומר “אה, הקוד מסריח, אני לא מבין מה כתוב פה”, אלא יש איזשהו מדד סובייקטיבי - למשל, אחוזי השגיאות או אחוז הזמינות של ה-Service או איזשהו מדד אובייקטיבי שהוא רלוונטי, בגדול, ירידה מה-SLO.

השאלה היא (1) האם שקלתם גישות כאלה? אם אתה מכיר? הייתי שמח לשמוע . . .

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

(רן) אבל ניסיתם למדוד? נגיד - כמות הבאגים, כמות או חומרת הבאגים?

• (גדעון) אנחנו מודדים את זה - וזה חלק מהסיבה שאני לא כל כך מתחבר לזה . . .
• כי יש לי, נגיד, אתה יודע - אני חושב שאם אתה מסתכל על קומפוננטה (Component) שהיא יותר “Frontend-ית”, לעומת קומפוננטה, נגיד, “Backend-ית”, לעומת קומפוננטה שהיא High-Performance Networking
• כמות הבאגים והחומרה שלהם - זה דבר מאוד מאוד שונה בין . . .
• זה שלושה סוגי קומפוננטות שיש אצלי - וכמות הבאגים שאתה תראה והחומרה של הבאגים והסגנון של הבאגים הוא מאוד מאוד שונה.
• אז נגיד, הקומפוננטה לא ה-High-Level Networking, אתה כנראה תראה הכי פחות באגים - אבל [מידת] ההרסניות שלהם תהיה הרבה יותר גדולה
• והצורך שלי, בשביל 20 צוותים, עכשיו להתחיל לבנות איזה שיטה נורא נורא טכנית - אני לא מתחבר . . .
• אני יותר מסתכל על . . . אני מניח שאם היינו חברה פי-שתיים יותר גדולה, אז הוא כנראה נצטרך להתחיל לחשוב על דברים כאלה
• אבל כשמסתכלים ב-Scope כזה, אתה רוצה לבסס דברים על שיח בעיני.

30:58 כשרק בנאדם אחד יודע מה קורה שם

(רן) יצא לך [גדעון] או אולי לך, אורי, להתקל במצב שבו ה-Product בא ודרש ואמר “אני רוצה שתתקן!”?

אז סיפרת את הסיפור של ה-Python, ואני סקרן לשמוע אם יש עוד סיפור . . .

• (גדעון) יש לי סיפור . . . שוב, אמרתי שיש לי מזל עם ארגון ה-Product שאני עובד איתו
• היו מקרים שהם באו ודרשו דברים שלא נדרשו מבחוץ.
• ה-Python 3 מבחינתם זה היה Feature
• זאת אומרת, בא לקוח ואמר “אני צריך א' ב' ג'” - הם לא הסתכלו על זה ככה.
• אבל היו אזורים אחרים שהם אמרו “יש לנו פה אזור בעייתי, בואו נדבר על זה” ואני כמובן מברך על זה.

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

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

אבל עכשיו צריכים להיות חמישה - או עשרים וחמישה - אנשים ופתאום . . .

• (גדעון) היו לנו סיטואציות כאלה, אגב, באמת באזורי ה-Networking אצלנו.
• ומה שראינו שקורה זה שאנחנו משקיעים יותר ויותר בהתמודדות עם הצרות האלה שבאות מה-Field, עד סיטואציה שאתה מתחיל לאכול יותר ויותר ויותר מהנתח שלך לתיקוני באגים או לשיפור של זה או שיפור שלו,
• שאתה בעצם מפסיק להשקיע ב-Feature-ים - ואז Product באים ואומרים “אני צריך יותר פיצ'רים! למה אתה משכיב חצי מהצוות על תיקון באגים?”

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

• (גדעון) כן, זו בעיה . . .

(רן) ל-Tech-Debt הזה דרך כלל יש שם [ויש גם שיר] - זה נקרא Bus Factor: כמה אנשים צריכים להידרס כדי שהמוצר “ילך קאפות” . . . וזה גם, זאת אומרת, זה Tech-Debt שרואים עכשיו על ימין ועל שמאל. אולי לא מחשיבים את זה ככה, אבל זה לגמרי . . .

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

(רן) נכון, נכון.

(רן) בסדר, טוב, אנחנו ממש ככה מגיעים לסוף זמננו, הזמן רץ כשנהנים.

אז תודה - תודה שבאת, שיחה מעניינת, ובואו - תצברו חובות, אך באחריות! כמו שתמיד אומרים בתוכניות הכלכלה . . . תודה רבה.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!