469 Software development in early stage startups with Shai Yallin

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

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

פרק מספר 469 של רברס עם פלטפורמה - הוקלט ב-9 באפריל 2024. אורי ורן חוזרים לאט לקצב ומארחים את שי ילין לשיחה על איך מהנדסים תוכנה בחברות צעירות: Do & Don’ts של חברות שאולי רק עכשיו התחילו.

שי מלווה לא מעט חברות כאלו - והוא גם מודרטור (בכנס האחרון) ומרצה ותיק בכנסי רברסים [How Scala promotes TDD ב-2013, Putting the 'D' in TDD ב-2015 ו-You (probably) Don't Need Global State Management ב-2022] וגם מארגן של כנסים אחרים.

01:40 רקע על שי ותנועת הזמישות

(רן) אז שי - כמה מילים עליך? ספר לנו עליך . . .

• אז אני שי. בשלוש וחצי השנים האחרונות עמצאי, כשאני מחלק את הזמן שלי בין שלושה תחומים עקריים בחיים שלי:
• יש לי שני ילדים - תום ואדם.
• אני עושה מוזיקה, בכל מיני קונסטלציות - חלק מהן יותר וחלק מהן פחות מצליחות מבחינה מסחרית ועסקית.
• ורוב הפרנסה שלי מגיעה מייעוץ לסטארטאפים וחברות שהן כבר לא סטארטאפים, או שהיו סטארטאפים או בדרך להפוך מסטארטאפים למשהו יותר מסודר . . .
• ובעצם, אני נותן שירותים לחברות שהן סטארטאפים או חברות שהן מיושבות יותר, של איך בונים מערכות וארגונים שקל לעשות להם שינויים.
• בעצם, אנחנו רוצים שגם . . . ככל שהחברה יותר צעירה, שגם נוכל לעשות שינויים לקוד, ל-Codebase, לתשתיות - וגם לארגון עצמו, בצורה יותר קלה.
• אנחנו רוצים גמישות, אנחנו רוצים פחות נוקשות - כי אנחנו עדין לא יודעים איך המערכת צריכה לראות, מהן הבעיות שנתמודד איתן, ואיך הארגון צריך להיראות ומה הבעיות שנתמודד איתן.
• וחלק ממה שמייחד את מה שאני עושה זה שאני עובד גם עם מנהלי פיתוח וגם עם מהנדסים.
• עם מנהלי פיתוח אני עושה יותר Mentoring וארכיטקטורה ותכנון של בניין הכוח.
• ועם עם המהנדסים אני עושה יותר דברים כמו Pair Programing ו ו-Code Reviews ו-Design-ים.
• ואז בעצם אנחנו נותנים מענה הוליסטי לאיך שאנחנו יוצרים ארגונים ומערכות שהם גמישים ושהם ניתנים

לשינוי בקלות.

(רן) כן, כמובן בתוך הנחה שסטארטאפ בדרך כלל “Doesn't know $h!t”, הוא לא יודע . . . כל מה שהוא יודע זה אולי שהוא גייס כסף ושהוא רוצה לייצר מוצר. אבל חוץ מזה לא הרבה, והדבר הכי חשוב זה גמישות - היכולת לבוא ולשנות כיוון . . .

(אורי) אני רוצה לאתגר את זה . . . כי באמת, סטארטאפ “Doesn't know $h!t”, בעיקר לגבי העתיד שלו - המוצר יצליח, לא יצליח? נצליח לגייס את האנשים הנכונים? אולי לא, אולי כן . . . נצליח לגייס כסף? אולי כן, אולי לא . . . אבל

אנשים באים לתוך הסטארטאפ עם איזשהו ניסיון חיים, בין אם הם Founder-ים פעם שנייה או . . . גם בחברות שהם

עבדו בהם, הם מגיעים עם “משהו” . . .

• (שי) זה מאוד נכון.
• אני חושב שמשהו שאני ראיתי זה ש-Founder-ים שהם 2nd Timers - הם כבר יודעים שהם לא יודעים . . .
• הם יודעים את הבעיות שלהם והם יודעים לחפש את הגמישות הזאת.
• לעומת פאונדרים שהם 1st Timers - שהרבה פעמים הם רצים מהר והם מנסים לתכנן קדימה, והם מקבעים דברים מוקדם מדי.
• בין אם זה לתת Title-ים מוקדם מדי, בין אם זה לפתור בעיות Scale שלא קיימות . . .
• כל מיני אופטימיזציות שאנשים עושים ושלדעתי הם לא הדברים הנכונים.
• עכשיו, גם אם אני מהנדס - הייתי מהנדס בחברה גדולה, ועכשיו אני מגיע לסטארטאפ - לא בהכרח הכלים שהשתמשתי בהם בחברה הגדולה יתאימו לסטארטאפ.
• ואם אני מהנדס מנוסה, אבל עדיין לא “אכלתי קרבות קשים כאלה”, אז אני עלול להיות מסוגל לעשות אופטימיזציה מוקדמת מדי - Over-Engineering - כדי לפתור בעיות, כי אני “מפחד מהלא-נודע”, כי אני לא יודע מה יקרה.

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

• [עוד רקע כאן - פרק 443 Hiring for strength, not skill with Sahaf from Hippo]

• (שי) ללא ספק, אני חושב . . . מה זה סתגלתנות? זה אדפטיביות, נכון? זה בעצם Agile, נכון? מה ש-Agile בא להגיד לנו . . .
• (אורי) . . . אנחנו מתרגמים את זה לעברית, כאילו . . .
• (שי) “זמיש”, נכון? הם קוראים לזה “זמיש” . . . אז “תנועת הזמישות”, שהופיעה לפני 20 ומשהו שנה - אני חושב שאחד הדברים שהם דיברו עליהם, זה שהמונח Agile היה פשרה
• הם בכלל רצו לקרוא לזה “אדפטיביות” או או “אדפטיביליות” או משהו כזה.
• כי בעצם, אנחנו רוצים לאמן את עצמנו להתמודד בצורה יותר טובה עם דברים שאנחנו לא יודעים מה הם יהיו
• (אורי) . . . לחזות אותם . . .
• (שי) נכון - אנחנו לא יכולים לחזות את העתיד, אין לנו יכולת לחזות את העתיד.
• והרבה פעמים, באופן אבסורדי, בניסיון לחזות את העתיד, בניסיון לפתור בעיות שתגענה - אנחנו עושים “הכנות למזגן”, אנחנו עושים מה שנקרא “YAGNI - “You Ain't Gonna Need It. בעברית זה “הכנה למזגן”, זה בדיוק מאוד יפה.
• ומה שקורה עם הכנות למזגן זה שבדרך כלל כשאתה צריך מזגן - אז ההכנה לא מתאימה לו . . .
• ואז יש לך שתי בעיות . . .
• (רן) . . . כבר יש התחממות גלובלית, צריך מזגן הרבה יותר גדול . . . כל מה שהכנת כבר לא רלוונטי . . .
• (שי) . . . התשתית לא רלוונטית, השקע-חשמל לא רלוונטי, עשית חור בקיר אבל אתה מתקין מזגן מפוצל . . .

06:44 מה מביא אותך לתת עצות?

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

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

08:02 בואו נתחיל ב-Monolith-ים ואחר כך נדבר - מחפשים צרות עם Monolith-ים ו-microService-ים

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

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

בוא נמנה כמה מהם - נדבר על מונוליטים [Monolith], נדבר על microservice-ים? . . .

• (שי) כן, יאללה - אני גם עשיתי על זה Blogpost לא מזמן [ - Of Rigid Microservices and Flexible Monoliths], והוא היה די שנוי במחלוקת . . .

(רן) . . . To be or not to be - Monolith or microservice” - let's go”

• (שי) אז התשובה היא כמעט קטגורית “להתחיל מ-Monolith” . . .
• נתקלתי בכמה מקרים: עבדתי בסטארטאפ - בעצם, המשרת-שכיר האחרונה שלי הייתה בסטארטאפ, שבו היה CTO שהחליט שהוא בונה Design מאוד מאוד מאוד Strict לחלקים של המערכת, כדי לאפשר לרוץ מהר ולפתח כל חלק בנפרד.
• אז הוא בעצם יצר אוסף של Inerface-ים והגדיר היטב את הממשקים ביניהם ואיך כל אחד מתנהג …
• ומה שקרה זה שזה יצר קשיחות מאוד מאוד מאוד גדולה - ואי אפשר היה . . . היה מאוד קשה לעשות שינויים ב-Interface-ים האלה
• בגלל שהתחלנו מ . . . אפילו לא התחלנו מ-microservices - הוא רצה להתחיל מ-microservices
• ואז אמרנו “רגע - לא צריך Process-ים נפרדים, בוא נעשה Modular-Monolith
• נשים את כל אותם מימושים בתוך אותו Process, הם ידברו אחד עם השני דרך הזיכרון - כאילו, In-process ולא דרך הרשת.
• אבל הייתה התעקשות להשאיר את ההגדרה של ה-Interface-ים ב-Protobuf, בקבצי IDL של Protobuf
• שזו בעצם שפה שהיא Language-Agnostic - היא לא קשורה לשפת פיתוח ספציפית, שמגדירה ממשקים של מערכות Web, מערכות אינטרנט.
• אז יש לנו Interface-ים, ממשקים, ויש לנו Instruct-ים . . .
• (רן) כשהטכנולוגיה לכשלעצמה היא מצוינת - רק לעוד חמש שנים או עשר שנים . . .
• (שי) הטכנולוגיה מעולה - אם צריך microservices . . . .
• אבל ברגע שאתה מכניס את העובדה שצריך לעשות כל שינוי ב-Protobuf ואז לג’נרט (Generate) קוד לשפת הפיתוח שאתה משתמש בה, זה הופך כל שינוי להרבה יותר קשה ומורכב.
• וזה בעצם כאילו זה אומר לאנשים “רגע - יש פה גבול, אי אפשר לשנות אותו” - ואז האנשים לא מפקפקים בגבול הזה.
• (רן) . . . או שהם עוקפים אותו בצורה מוזרה . . .
• (שי) . . . או שהם עוקפים אותו בצורה מוזרה . . . היה לי לקוח שהתחיל מ-microservices, כי היו לו מהנדסים שהגיעו מחברות שבהן עשו microservices.
• ואז הם התחילו את המערכת עם מספר לא קטן של microservices ב-Node - ואז אי אפשר לעקוף את זה בצורה הזאת, זה ממש כאילו “לצאת לרשת” . . .
• ואז אתה משלם את “המס” של בעיות Scale - לפני שיש לך בעיות Scale . . .

(אורי) אני חושב שאם אנחנו מדברים על microservices, תמיד יש את הוויכוח “Monolith או microservices” וכו' . . . ל-microservices יש תכונה, שהיא טובה מאוד ב-Scale - אבל פחות ב-Scale של מערכת או של ב-Scale הטכנולוגי או ה-Performance או זה, אלא דווקא ב-Scale של ארגון הפיתוח . . .

(רן) HR-י . . . . נכון, לכל צוות יהיה את ה-Service שלו - או או שניים-חמישה שלו . . .

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

(רן) כן - אבל כל אחד שמסיים עכשיו לימודים והולך קצת ללמוד על איך נראה עולם הפיתוח “האמיתי”, אז הוא לומד שאוקיי, יש Bug Management systems ויש Git - “וצריך זה” ו”צריך microservices”, נכון? זה מה שלומדים - לצערנו. הרבה שמסיימים את הלימודים שלהם באים ואומרים “אוקיי microservice-ים! זה הדבר, את זה אני צריך להכיר וזה מה שאנחנו הולכים לעשות בחברה שלי!”. או, מצד שני - אם הייתי בחברה גדולה אחרת, ושם כולנו עשינו microservices, אז ברור שגם בסטארטאפ שלי, אני מראש אבנה אותו Robust-י עם microservices - ושי אומר שזו טעות. אתה מקדים בהרבה מאוד את מאוחר, ואתה הולך לשלם על זה מחיר מאוד כבד בזמן שאתה בכלל לא צריך.

(אורי) הרבה פעמים משחררת קצת התפיסה הזאת של “הקוד הזה הולך להימחק” . . . .

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

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

• (שי) אני חושב שאנשים מסתכלים על תוכנה בצורה לא נכונה - אני חושב שאנשים מסתכלים על תוכנה כ”משהו שאנחנו בונים”.
• אבל תוכנה זה לא משהו שאנחנו בונים - זה משהו שאנחנו “מגדלים”, כמו גינה, כמו עץ.
• וכשהעץ צעיר, אז הוא שתיל קטן, עם גבעול רזה - והוא יכול להתכופף.
• וככל שהוא גדל ומזדקן, אז הגזע מתעבה ונהיה יותר עצי וקשה.
• ומערכות תוכנה הן אותו הדבר - הן מתחילות כמשהו מאוד קטן, ואתה רוצה לגדל אותן באופן הדרגתי.
• אין לך מושג מה יהיו בעיות ה-Scale שיהיו לך.
• אין לך מושג מה יהיו “גבולות הגזרה” - מה שנקרא ה-”Bounding Context”, ההבדלים ב-Domain-ים השונים שאתה הולך להתעסק איתם.
• עוד חצי שנה, עוד שנה, עוד שנתיים . . . מתי שזה לא יהיה שתזדקק - אם בכלל תזדקק ל-microservices.
• וכמו שאורי אמר - microservices זה פתרון לבעיה.
• זו לא אסטרטגיית פיתוח או אסטרטגיית ארכיטקטורה של קוד - זה פתרון לבעיה שהיא בעייה ארגונית: איך אני מאפשר לצוותים שונים לעבוד בו זמנית, לעשות Deployment בו זמנית, בלי לדרוך אחד לשני על הרגליים, בלי לעשות Coupling בין פיצ'רים (Features) שלא קשורים אחד לשני.
• לפעמים, microservices הם גם פתרון לבעיה ארכיטקטונית - אם יש לי שתי מערכות שונות, אחת צריכה להיות ב-High-Throughput אבל לקריאה בלבד ואחת היא ב-Throughput יותר נמוך והיא לקריאה וכתיבה, אז זה הגיוני לחלק ל-microservices, ולעשות איזשהו תהליך של להעתיק את המידע ביניהן.
• אבל אלו מקרים מאוד מאוד מאוד ספציפיים, ורוב החברות לא צריכות microservices.
• בטוח לא עכשיו - בשלב הראשון, כשאנחנו רק מגששים ומנסים להבין מה ה-Product-Market Fit שלנו.

14:55 סיכום ביניים - תבנה “Monolith טוב”

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

(אורי) . . . מה שמביא לכם את ה-Product הכי מהר . . . .

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

• (שי) אני רוצה להוסיף ש-Monolith - יצא לו שם רע . . . .
• כאילו, זו נהיתה מילה גסה כזאת - “מה? Monolith?! מה זה, “קוד ספגטי”? זה Big Ball of Mud . . . .
• לא - זה לא חייב להיות ככה.
• תבנה Monolith טוב, תעשה Refactor-ים תכופים בזמן שאתה בונה את ה-Monolith.
• אתה תקבל Monolith מודולרי.
• וכשתרצה - אם תרצה - לקחת איזשהו נדבך ממנו ולהוציא אותו החוצה ל-Process נפרד, זה פשוט יהיה להרים אותו ולהעביר אותו הצידה לשתול אותו ב-Process אחר.
• כמו שאנחנו עושים השתלה של עץ או של שתיל מגינה לגינה.

16:13 מה הסיפור של טסטים?

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

אז טסטים בטוח לא צריך בשלב הזה . . . .

• (שי) . . .

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

מה הסיפור של טסטים?

• (שי) אז אני אגיד שקודם כל - המטרה של טסטים זה לא למצוא באגים.
• זאת אומרת, כשאני מוצא באג, אז אני משחזר אותו בטסט שנכשל, ואז אני יודע שהבאג הזה לא יחזור.
• אבל המטרה של טסטים זה להוכיח לי שהמערכת עובדת.
• זאת אומרת, אם עכשיו כתבתי קוד, והקוד הזה עושה משהו והוא עובד - זה מקרי שהוא עובד . . . אין לי שום הוכחה שהוא עובד.
• אני רוצה את היכולת לדעת, בכל רגע נתון, שהמערכת שלי עושה את מה שהיא אמורה לעשות, שהפיצ'רים עובדים.
• עכשיו, זה לא משנה אם אני עכשיו כותב Prototype, ואני מנסה להתכנס על Product-Market Fit, או שאני כבר בשלב של Expansion או של Hyper-Growth, של גדילה מהירה.
• אני עדיין צריך לדעת שהפיצ'רים עובדים - וזה מגוחך בעיניי שאנשים לא כותבים טסטים לפיצ'רים שלהם.
• עכשיו, זה לא אומר שאתם צריכים לכתוב עכשיו מלא מלא מלא Unit Test-ים . . .
• צריך למצוא את “נתיב הזהב” שבין לכתוב יותר מידי טסטים שבודקים פרטי מימוש, ואז אנחנו בעצם מבזבזים את הזמן שלנו על שטויות, על לכתוב טסטים שאף אחד לא צריך ושרק יפריעו לנו לעשות שינויים, לבין לא לכתוב טסטים בכלל.
• אז אני רוצה להציע איזושהי גישה, שהיא כמעט ממשיכה את הדרך של הגישה שהצעתי כשאמרתי “בוא נתחיל

מ-Monolith ולא נתחיל מ-microservice.

(רן) אוקיי . . . אז מהי “גישת הטסטים” בעולם הזה?

• (שי) אז בגדול, אני בודק פיצ'רים.
• אני רוצה להתחיל - אני מתחיל מערכת, יש לי איזושהי הנחת יסוד, השערה לגבי מוצר שיכול לעבוד - אז אני כותב טסט לדבר הזה.
• אם אני כותב מערכת Web-ית אז אני כותב טסט במשהו כמו Playwright, או איזשהו Framework UI כזה.
• ואני אכתוב טסט שהוא מאוד מאוד “גס” באופי שלו.
• לצורך העניין, אם אני בונה חנות, אז הטסט יכול להיות “לקוח יכול לקנות מוצר” . . .
• (רן) כלומר, לא Unit Test, נדגיש.
• (שי) ההיפך . . . ההיפך הגמור - זה End-To-End Test: הוא רץ לאט, הוא רץ על דפדפן . . .
• וכל עוד אני מנסה להתכוונן על Product-Market Fit, אני אכתוב מעט End-To-End Tests כאלה
• שהם ישתנו רק כשהדרישות תשתננה - ולא כשהמימוש ישתנה.
• והם יהיו “רשת ביטחון" - שאני יודע שאני “עובד”, שאני תמיד עובד.

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

אבל מתי כן? מתי כן אתה תתחיל לעשות את זה?

• (שי) אז כמו שאמרנו קודם ש”המערכת שלנו היא עץ", אז כשהעץ מתחיל “להתעבות” - כשהמוצר מתחיל להתקבע ולהתקשח. זאת אומרת, כשאנחנו כבר יודעים מה אנחנו עושים - אז אנחנו רוצים להעמיק את הטסטים, לבדוק יותר מקרי קצה.
• אנחנו רוצים אולי לקחת חלק מה-End-To-End טסטים האלה, ולהפוך אותם לטסטים שהם רצים יותר מהר.
• אז אם אנחנו יכולים, אנחנו נריץ - לבדוק פיצ'רים בתוך Process בזיכרון.
• באמצעות משהו שנקרא Hexagonal Architecture, אנחנו נרים מערכת - עם Fake-ים במקום כל מה שיוצא החוצה מהמערכת, ואז אני לא יוצא מתוך גבולות ה-Process.
• ואז אני מקבל Performance של Unit Test - ורמת Scope של End-to-End Test, שבודק פיצ'רים ולא יחידות תוכנה, שהן כמעט מקריות, שהן Implementation details, שהן פרטי מימוש של המערכת שלי.

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

(רן) אני קורא לזה “תיעוד” - אבל גם זיכרון ארגוני.

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

22:26 זה הולך להיות ב-Rust בוודאות

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

(אורי) אפשר להשקיע? . . .

(רן) . . . אבל אני יודע דבר אחד - זה הולך להיות ב-Rust בוודאות [דותן מרגיש הפרעה בכוח…], , כי זו שפה יפייפיה, היא Type-safe, והיא ממש מגניבה. מה דעתך?

• (שי) דעתי היא שאתה לוקח סיכון . . . .
• למה אתה לוקח סיכון? כי אתה בחור מאוד חכם ומאוד ותיק ומאוד מנוסה - ואתה יודע שהשפה הזאת טובה לך.
• אבל אתה לא תצליח, כנראה, לגייס צוות שמורכב מהאנשים כמוך.
• אתה תגייס צוות של אנשים שהם הרבה פחות מנוסים . . .
• עכשיו, אתה יכול ללמוד אותם Rust - אבל את הזמן שאותו אתה משקיע בללמד אותם Rust, או שהם משקיעים בללמד את עצמם Rust, הם היו יכולים להשקיע ולכתוב לך פיצ'רים ב-Go [עכשיו אלון מרגיש הפרעה בכוח…] או ב-TypeScript או בכל שפה שהיא יותר נפוצה.
• אז כשאני הולך לפתח מערכת ב-Rust - ואני עשיתי את הטעות הזאת . . .
• לא יודע אם אני קורא לזה טעות, אבל אני העברתי את Wix לפתח ב-Scala . . .
• ו-Scala שפה נהדרת, מדהימה - ומתקמפלת מאוד לאט, ומאוד קל לעשות בה “פשעים נגד האנושות” . . . .
• ועשור אחרי שהעברתי את Wix ל-Scala, או 12 שנים אחרי שהעברתי את Wix ל-Scala, אני שומע קולות מ-Wix, של אנשים שאומרים “למה אנחנו עובדים ב-Scala?!”
• אז בזמנו, כשהיינו חברה של 30-40 מהנדסים, זה היה איזשהו “Differentiator” - איזשהו משהו מבדל.
• יכולתי להגיד “אנחנו כותבים ב-Scala, ומי שרוצה לכתוב ב-Scala יבוא ויעבוד ב-Wix!”
• וזה היה מגניב לנו - כשאתה סטארטאפ חדש, אתה רוצה כמה שפחות לבדל את עצמך ברמה הטכנולוגית, כדי שתוכל . . . . כדי שלא לצמצם את ה-Funnel של הגיוס שלך, שתוכל לגייס אנשים בלי שהם יצטרכו לחשוב עכשיו “האם אני רוצה להיכנס ל-Rust? מה אני צריך את הדבר הזה בחיים שלי?” . . . .

(רן) כן, אז אתה מסתכל מהפן של הגיוס. מה לגבי “הצרות הרגילות” - Community Libraries, תשובות של - כולם עוד אומרים “Stack Overflow!”’ אבל “תשובות של GPT” - וכו’? האם גם זה Concern בעיניך?

• (שי) בוודאי.
• זה לא שקהילת ה-Rust היא לא קהילה ענפה ומלאה באנשים נלהבים . . .
• פשוט, באופן מאוד מאוד פרקטי - יש הרבה יותר אנשים שכותבים ב-TypeScript או ב-Go או ב-Java
• ולכן יש לך יותר סיכוי לקבל תשובות ולראות דברים שכבר עשו - פתרונות שכבר עשו לבעיות שאתה עלול להתקל בהן.
• גם ספריות - כאילו, יש לך הרבה יותר ספריות ב-JavaScript מאשר ספריות ב-Rust
• והרבה יותר בעיות כבר פתורות בעולם של JavaScript לעומת העולם של Rust.

25:21 אובססיה לטכנולוגיה - על Framework-ים וחיות אחרות

(רן) עכשיו - נניח שאני הולך לפתח משהו בעולם הLLMs, סתם ככה כי בא לי, כי זה מה שכולם עושים היום [לא סתם - Surviving the Hype - How to Not Let the Success of Your Domain Ruin You / Rachel Wities], ובא לי, ואני רואה שיש Framework ממש מגניב שנקרא LangChain, ווואלה דווקא נראה לי דווקא סבבה, אז אולי אני אאמץ אותו אליי, ונבנה את הכל ב-LangChain . . . . איזו טעות אני עושה פה?

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

• אבל האם אני צריך את כל היכולות של ה-Framework הזה? כנראה שלא . . .

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

אבל האם אין מקרים שבהם Framework דווקא יכול להיות שימושי? אני אתן אולי את הדוגמה הכי טריוויאלית:

אם אני הולך לכתוב משהו ב-Web, אני לא אכתוב את הכל מאפס ב-HTML ו-JavaScript, אני כנראה אשתמש

ב-React או חברים . . . לגיטימי?

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

• (שי) אני חושב ש-React היא דוגמה מצוינת, כי-React היא לא Framework - היא ספרייה.
• היא מאוד מאוד קטנה ופשוטה, וזה נכון ש-React עם Hooks זה כבר קצת Framework, ו-Next זה ממש Framework . . . .
• ואני אגיד לך לא להשתמש ב-Next - בשום פנים ואופן אל תשתמש ב-Next.
• אין לך שום סיבה להשתמש ב-Next - היא נועדה לפתור בעיות שאין לך.
• אבל React היא ספרייה, היא קטנה - היא לא “אולר שוויצרי”, היא “סכין קומנדו”.
• היא יודעת לעשות דבר אחד - וזה לרנדר (To Render) UI
• וזו בדיוק הדוגמה למשהו שהוא סטנדרט דה-פקטו היום בתעשייה.
• גם הרבה מאוד Framework-ים אחרים לקחו מ-React רעיונות או משתמשים ב-JSX כמו ש-React עושה.
• יהיה לך קל להביא אנשים שמכירים את זה, יש Best Practices, יש סטנדרטים . . .
• ועדיין - אני ממליץ לא לעשות Coupling של הקוד שלכם לספרייה או ל-Framework.
• אני גם לא אומר לעשות Abstraction Layers או Interaction Layers - שכבות הפשטה מעל הספרייה הזאת.
• אבל אני כן אומר שצריך להיזהר ממצב שבו אני מתעסק, כמו שאורי אמר, ב-Yak-Shaving, בלהתאים את עצמי לתוך ספרייה או Framework.
• כי אז בעצם אני מכניס את עצמי לשבלונה - ואני מגביל את עצמי ביכולת שלי לגדול ולהתפתח.

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

שתשקיע רק ב”לרכב על השור הזה” . . .

• (שי) אתם לא צריכים Kubernetes, אתם לא צריכים Next, אתם לא צריכים Next.js, אתם לא צריכים Kubernetes, אתם לא צריכים את Elixir, אתם לא צריכים את LangChain . . .
• אתם צריכים לכתוב את הקוד הכי פשוט שפותר את הבעיה שאתם חושבים שאתם רוצים לפתור.
• ולהביא זה למשתמשים ולשוק ולראות איך מקבלים את הקוד שלכם, איך מקבלים את המערכת שלכם, איזה פיצ'רים צריך . . .
• ותפתרו את הבעיות כשהם יקרו, ולא לפני.

29:40 סיכום ביניים

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

יהיה לכם קשה לגייס. אז לזה קראנו “אובססיה לטכנולוגיה”.

לפני זה דיברנו על Testing - האם, מתי ואיך?; וממש לפני זה דיברנו על “בואו נתחיל ב-Monolith-ים ואחר כך נדבר”

30:11 איך מנהלים חוב טכנולוגי?

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

וזה הכי קל, כאילו בסטארטאפ, לבוא ולהגיד “אוקיי, אוקיי, את זה אני אעשה אחר כך”, “פה אני אשאיר לי עצמי To-Do”, “פה אני לא באמת אסגור את ה-Security hole הזה”, “פה אני לא באמת אטפל ב-Performance” - ולפעמים זה לגיטימי. אבל איך אחר כך מתמודדים עם זה?

• (שי) קודם כל בוודאי שזה לגיטימי.
• למעשה, כמו שאמרתי - אני, במוצרים חדשים . . .
• אגב, לא בהכרח בסטארטאפ חדש - גם אם אני עכשיו בתוך חברה גדולה ואני בונה מוצר חדש, ואנחנו עדיין לא יודעים אם למוצר הזה יש שוק
• אני אנסה להיות “כאילו שאני בסטארטאפ” - אני אנסה להיות הכי Lean שאני יכול, בתוך המגבלות של החברה שאני נמצא בה.
• אז אני לא רוצה לפתור בעיות Performance ואני לא רוצה לפתור בעיות Security עכשיו - אני כן רוצה לייצר מערכת שבה אני אוכל לעשות את זה אחרי זה בקלות.
• זאת אומרת, אני רוצה שהקוד שלי יהיה גמיש לשינויים.
• זאת אומרת שאני רוצה טסטים מספקים כדי להגן עליי.
• ואני רוצה רגע לדבר על המונח “חוב טכני” - המונח “חוב טכני” הוא מונח שהוא גם בעייתי . . .
• כי לא כל החוב הטכני הוא בעייתי באותה רמה.
• כי אנשים אומרים “יש לי פה Class שכתבתי - והוא מכוער! זה חוב טכני!”
• ואני אגיד שזה חוב טכני אם ה-Class הזה משתנה הרבה - אבל אם ה-Class הזה לא משתנה אף פעם, אם כתבתי איזה Adapter לאיזה ממשק SOAP של חברת ביטוח, שהשתנה בפעם האחרונה ב-2004 . . .
• וזה קוד מגעיל - אבל אף אחד לא נוגע בו אף פעם, או שפעם בשנה מישהו נכנס לשם ועושה איזה תיקון
• האם זה בסדר שהקוד הזה יהיה מגעיל? אני טוען שכן.
• כי אנחנו רוצים שקוד יהיה נקי כדי שנוכל לקרוא אותו - קוד שמשתנה הרבה זה קוד שקוראים הרבה.
• אז איפה שיש הרבה שינויים - אנחנו רוצים להשקיע ולפרוע Technical Debt, לפרוע חוב טכני.
• איפה שאין הרבה שינויים - זה לא חוב טכני, זה פשוט קוד מכוער.

(אורי) אני רוצה לתת עוד אספקט של “חוב טכני" ו”חוב מוצרי” - יש גם דבר שנקרא “חוב מוצרי”: המוצר “לא מדויק”. זה משהו שלמדתי מהרצאה בכנס רבסים האחרון [מניח שזה - It’s time to pay off your management debt / Daniel Korn]: בטח בסטארטאפים, כשאתה בונה משהו ולא בטוח שהוא יעבוד ושהוא יעבוד טוב - ויש מצב טוב שתצטרך לזרוק את הקוד הזה - תאפשר לעצמך “תספורת” . . . זאת אומרת, לפני שאתה משלם את החוב הטכני, תראה אם באמת המוצר הזה, יש לו אורך חיים רלוונטי. כי אם לא, זרוק את הקוד. החוב מחול - פשוט זרוק את הקוד.

(רן) כן . . . “תספורת”, רק לתרגם מעולם הפיננסים, זה "להשליך לפח”, לשכוח מהחוב.

• (שי) כי בעצם, מה אנחנו אומרים? יש פה מדד מאוד פשוט: איפה אני רוצה לפרוע חוב טכני?
• אז אמרנו אחד - זה מקומות שבהם הקוד משתנה הרבה.
• אנחנו קוראים לזה “Hotspot”.
• יש מערכות שעוברות על Git ומנסות למצוא “Hotspot”.
• איך מוצאים Hotspot? זה קל - זה הרבה מאוד Commit-ים [טובים!] לאותה שורת קוד, או הרבה מאוד Committers לאותה שורת קוד, או לאותן שורות קוד, או לאותם קבצים.
• אז יש לנו איזשהו משהו שיחסית קל לכמת אותו.
• יש גם מערכות, כמו למשל CodeScene, שיודעות לתת לנו את האינפורמציה הזאת.
• ומקום שני זה באמת מוצרים שלא משתמשים בהם, או פיצ'רים שלא משתמשים - וגם פה אפשר למדוד את זה.
• באמצעות מערכות Monitoring, באמצעות BI, אנליטיקות (Analytics) - אני עכשיו מכניס איזה Mixpanel ואני רואה במה משתמשים.
• ווואלה - אם לא משתמשים בזה, או אם משתמשים בזה מעט, ואני רואה שהפיצ'ר הזה עכשיו “נרקב” לאט לאט, או קמל לאט לאט, אז וואלה, כן, תן לו למות.

(אורי) בשלב מסוים התחלנו להגדיר שלבים בפיתוח מוצר. קראנו לזה Crawl-Walk-Run - [עוד על זה ב-437 Refactoring (and Observability) with Omer van Kloeten]. ב-Crawl, אם אני עכשיו כותב קוד שהוא Crawl - לא מעניין אותי החוב הטכני. כי אם הוא לא יצליח, המטרה שלו זה ניסיון, פשוט לנסות, לראות אם המוצר עובד, תופס מים, מעניין את מישהו. אז אם אני ב-Crawl, והמוצר לא יצליח, אז ברור שלא שווה לי לעבוד יותר מדי על החוב הטכני אלא פשוט לזרוק את הקוד. אם הוא כן יצליח אז אוקיי - צריך להתחיל לתכנן אותו ל-Scale, צריך להתחיל לתכנן אותו להרבה משתמשים . . . הוא גם יכול להתפתח כ-Hotspot פתאום, אז בטח ששווה לי להתחיל לטפל בחובות הטכניים שלו.

• (שי) נכון - אני חושב שזה גם המשך ישיר של הקו שדיברנו עליו קודם, נכון?
• אנחנו רוצים להיות גמישים, אנחנו רוצים להיות אדפטיביים, אז כאשר אני אני מתחיל, כאשר אני ב-Crawl, אני בעצם אותו שתיל דק וקטן.
• ואז אני רוצה שיהיה לי Coverage קטן של טסטים, אני רוצה להיות Monolith שקל לעשות בו שינויים - ואני רוצה להשתמש בטכנולוגיות פשוטות ומוכחות.
• ואני לא רוצה להשקיע הרבה . . .
• וככל שהזמן חולף והמוצר מתמצק ונהיה יותר מדויק, אני אתחיל לעשות Refacr-ים אופורטוניסטיים (Opportunistic).
• בגלל שיש לי טסטים אז אני בטוח - אני יכול לעשות את ה-Refactor-ים האלה, ואני יודע שאני לא אשבור שום דבר, אין לי פחד משינוי.
• ולאורך זמן, החוב הטכני פשוט “ייפרע לבד”.
• ואם אני מוצא את עצמי לא נוגע במוצר הזה יותר, אז אני גם לא צריך לעשות לו Refactor-ים ואני לא צריך לפרוע את החוב הטכני.
• זה כאילו מין כזה משהו שהוא מאוד הוליסטי, לשיטתי ולאיך שאני מסתכל על זה.

(רן) בסדר גמור.

36:21 חוק Conway הדו-כיווני

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

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

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

כמה אתה נתקל בזה?

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

(אורי) . . . הם פשוט תמונת-מראה ברוב המקרים.

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

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

זה נכון שאם אתה שובר דברים ל-microservices, אז פתאום אתה יכול ברמת הגרנולריות (Granularity), שהופכת לגרנולריות של ה-microservice - אבל זה נהיה יותר קשיח.

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

כאילו, “Interface על Interface” - “שכבת אבסטרקציה” . . .

(רן) אתה בא לדבר עם מנהל שלך והוא אומר לך “אל תדבר איתי - דבר איתו” . . .

(אורי) כן . . .

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

• (רן) אורי - אנייה! אתה יודע מה זו “אנייה”?

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

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

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

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

• (שי) כן, זאת אומרת - יש את ה-Level שלך, איפה אתה ברמת הוותק המקצועי
• ואז אתה יכול להיות מנהל פיתוח ב-Level מסוים או Individual Contributor ב-Level מסוים.
• (אורי) . . . באותו Level.
• (שי) אני חושב אבל שבעצם, הבעיה של ה”לעשות שינוי ארגוני” היא קצת בראש שלנו - והיא קצת אמיתית.
• מצד אחד, קשה לקחת לאנשים Title-ים - אבל אולי, מראש, היינו צריכים להימנע ולתת Title-ים מוקדם מדי, ואז היה לנו יותר קל לעשות שינויים.
• וגם פה, לפעמים זה משהו שלוקח זמן - כמו שלוקח זמן לעשות Refactor למערכת גדולה ולפרק אותה ל-microservices, אז אתה לא עושה את זה בין לילה.
• גם לשנות המבנה של הארגון - אתה לא עושה את זה בין לילה, אתה חותר לשם לאט לאט.
• אתה מציב לך איזשהו “כוכב צפון”, ואתה לאורך כמה חודשים מגיע לשם.

(אורי) ולא דיברנו בכלל על אבולוציה של תרבות . . .

(רן) בוא, אורי - יש הרבה דברים, יש לנו Backlog . . .

(אורי) כן . . .

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

42:26 סיכום וסיום וגמישות

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

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

(אורי) למחול.

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

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

ודיברנו על “בואו נתחיל ב-Monolith-ים” . .

ובמטא, דיברנו על מערכות תוכנה - וגם על מערכות של אנשים, נכון? איך אפשר לעשות Refactor לא רק לתוכנה,

אלא גם לצוותים ולאנשים, ככה שבסופו של דבר נהיה כמה שיותר אג'ילים (Agile). איך אמרנו בעברית? “זמישים” . . .

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

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

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