מפגש קבוצת ה Software Craftmenship מספר 9 בבית SAP ברעננה

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

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

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

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

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

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

אני מסתובב המון בארגונים שיש בהם מערכות מתמוטטות (לא סתם אני Bug Exterminator). אני נתקל שם בהרבה מפתחים שעושים טעויות ברמת הקוד הבסיסי. יש הרבה שלא מבינים אלף בית של ניהול זכרון בקוד מנוהל. יש הרבה שמשתמשים בפונקציות הלא נכונות, להשגת המטרות הלא נכונות (שימוש לא נכון ב API). אני כל פעם מורט מחדש את השערות (שאין לי), כשאני רואה קטעי קוד, שמתאימים לתיכוניסט שלמד זה עתה תכנות, ולא למפתח מקצועי, שאמור להתיחס לכתיבת קוד כ "תורתו אומנות", ושיש לו גאווה מקצועית, לא לעשות Check In, לקוד, שהוא יודע שיש בו בעיות.

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

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

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

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

זה שהיה למישהו נסיון רע עם ארכיטקטים לא מקצועיים (ושוב אנחנו חוזרים לנושא של מקצוענות), לא משנה את העובדה, שהארכיטקט והארכיטקטורה קריטיים להצלחת הפרויקט. ואני לא מקבל את הטיעון שהארכיטקט מבזבז את זמנם של המפתחים בזמן שהוא עושה את הארכיטקטורה. אני בדעה שלפני שלוקחים שישים מפתחים, ומתחילים לכתוב קוד של מוצר, במוד של Free Running (או Agile או Scrum), רצוי מאד שמישהו יראה את התמונה הכללית, יעבור על ה Use cases, יעשה את ה Decomposition, ויבנה ארכיטקטורה שתעמוד בפני כל שינוי שהמערכת אמורה לעבור בשנים הקרובות. כי אם לא תעשה את זה, תקבל מערכת, שעלויות הייצור והתחזוקה שלה, הן הרבה מעבר למתוכנן ולצפוי. וכן, עדיף שצוות של 60 מתכנתים ישב שלושה חודשים, ולא יעשה כלום בקוד של הפרויקט, אלא יקדיש את הזמן ללימוד של טכנולוגיות, וכלים, ו Coding Standards, בזמן שהארכיטקט יושב ועושה את ה Decomposition. במקום לרוץ לשום כיוון, ולקבל מהר הרבה קוד, שהדבר הנכון היחידי שצריך לעשות איתו, הוא לזרוק אותו לפח.

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

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

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

טוב, הוצאתי מספיק אש וגופרית על הנושא הזה, ובואו נעבור לנושא הבא. הדיון על Scrum וכל שאר נושאי ה Agile למיניהם לא עניין אותי יותר מדי, כל טכניקה שתגרום למפתחים לכתוב קוד מקצועי ונכון טובה בעיני. שכל ישר תמיד חשוב. וכמו שאמר אחד המשתתפים (שהידע שלו ב Scrum רב משלי), ניתן להסביר מה זה Scrum בכמה שעות, ולא צריך הסמכה ו Certification בשביל להיות מומחה ומיישם של עקרונות של "שכל ישר". מה שחשוב זה התוצאה הסופית. קוד שעונה למפרט, ונכתב לפי כללי הארכיטקטורה שקבע הארכיטקט. כשאני למדתי "שכל ישר" בפרויקטים, קראו לזה (בעולם המיקרוסופט) MSF. היום כולם מכירים את זה כשבלונה של פרויקט ב TFS, שאף אחד לא יודע בדיוק איך משתמשים בה. אהבתי את הקטע של ה Least Capable Manager בתור מנהל האיטרציה, יש בזה הרבה חכמת חיים.

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

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

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

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

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

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

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

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

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

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

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

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

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