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

25 בדצמבר 2011

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


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


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


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


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


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


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


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


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


yomuledet 001yomuledet 002


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


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


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


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


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


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


yomuledet 011


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


yomuledet 024


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


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


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


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


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


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


yomuledet 026


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


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


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


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


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


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


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

הוסף תגובה
facebook linkedin twitter email

להגיב על אילן קירשנבאום לבטל

האימייל לא יוצג באתר. שדות החובה מסומנים *

18 תגובות

  1. אלעד סופר26 בדצמבר 2011 ב 8:57

    גדי,
    כרגיל סיכום מצויין של הפגישה, לי הפעם לא היה זמן לעשות את זה :).
    אני אישית מסכים עם כל מילה במאמר הזה!
    אלעד.

    הגב
  2. אורי לביא26 בדצמבר 2011 ב 9:20

    שלום גדי,

    תחילה תודה רבה על הפוסט המצויין!

    (מקריאת הפוסט שלך) אני חושב שהמפגש השיג את המטרה!

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

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

    תודה ונתראה במפגש הבא שכולו יוקדש לקטה מאוד מאוד מעניינת (שאותה אגב לא הזכרת 🙂 )

    אורי

    הגב
  3. Shlomo26 בדצמבר 2011 ב 9:31

    וואי (איך כותבים את המילה הזו)

    אתה פותח כאן תיבת פנדורה 🙂

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

    ארכיטקטורה:

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

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

    נקח לדוגמא את CodeFirst – בעיני זה בא לפתור בעיית ארכיטקטורה שבה הקוד שלך תלוי ב – Entity Framework ולא רוצים שאובייקטי המודל יהיו תלויים בשכבה מסויימת וירשו ממחלקה של מייקרוסופט, ובמידה ויכתוב POCO ניתן יהיה להחליף בקלות את המודל, זו מחשבה נכונה, אבל אם מחליטים מראש שבשנים הקרובות לא נחליף את שיטת העבודה ונעבוד עם EF, אין סיבה להשתמש ב – CodeFirst שמסבך את העבודה ברמות ועדיף להשתמש ב – ModelFirst.

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

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

    מפתח טוב:

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

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

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

    הרב דוטנט

    הגב
  4. GadiM26 בדצמבר 2011 ב 12:42

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

    הגב
  5. GadiM26 בדצמבר 2011 ב 12:47

    שלמה חביבי,
    תודה על המשוב, ועל המאמץ החריג.

    הגב
  6. רון קליין26 בדצמבר 2011 ב 12:53

    וואו, כל הכבוד על הפוסט המושקע עצמו!

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

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

    [ואני חושב שהתכוונת ל Knuth. בקטנה.]

    הגב
  7. GadiM26 בדצמבר 2011 ב 13:33

    הי רון,
    בקטנה, תיקנתי. תודה.

    הגב
  8. ליאור שכטר27 בדצמבר 2011 ב 9:13

    היי גדי,

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

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

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

    1. ארכיטקטורה ותפקיד הארכיטקט

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

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

    למה כוונתי?

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

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

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

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

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

    בהקשר הזה הייתי ממליץ על הספר The Design of Design מאת Brooks, שמשתף קצת מנסיונו הרב על תהליכי תכן בדיסציפלינות שונות, גם תוכנה.

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

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

    2. מתכנת טוב

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

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

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

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

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

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

    למה כן התכוונתי?

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

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

    דוגמה נוספת למושג יחסית לא מורכב שאני לא בטוח כמה מבינים אותו כמו שצריך היא שימוש במספר threads בצורה יעילה – תזמונים ונעילות; שימוש בטיפוסים שהם immutable וכו'.

    עוד דוגמה למושג שאני לא בטוח כמה מבינים אותו טוב הוא הורשת מחלקות (class extension) – מנגנון שלרוב לא נעשה בו שימוש נכון.

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

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

    יותר מכך, מנסיוני, אנשים שמכירים את מושגי הבסיס טוב גם לומדים APIs הרבה יותר מהר ויודעים להשתמש בהם יותר טוב.

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

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

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

    הגב
  9. עדי27 בדצמבר 2011 ב 18:10

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

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

    אני מעדיף את החריפות והזריזות הצברית על היעילות היפנית חסרת המעוף.

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

    הגב
  10. GadiM27 בדצמבר 2011 ב 20:51

    הי ליאור,
    אני חולק עליך בנושא הארכיטקטורה, בכמעט כל נושא שהעלית בתגובה שלך, אבל אני מעדיף להגיב בצורה של Post, ולא בצורה של תגובה. אז המשך יבוא…

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

    הגב
  11. עופר זליג27 בדצמבר 2011 ב 21:23

    וואו גדי,

    איזה פוסט מושקע. כל הכבוד.

    חיכיתי לסוף הקריאה עם Stack של דברים בראש אבל עכשיו כשסיימתי לקרוא, מסקנתי היא שאני מסכים איתך בכל מילה.

    זאת למעט הערה (או הארה) על נושא מסוים אחד: QA.

    הבאזז האחרון הוא לא להחזיק אנשי QA לשוטף. רגע, אל תסקול אותי באבנים.

    אם אתה מאזין לפודקאסט של אורי ורן (ואני בטוח שאתה מאזין) וקורא ומשתתף במעגלים המקצועיים הרלבנטיים, בוודאי שמעת על Continous Deployment, כשיטת עבודה במסגרתה למפתח הבודד יש הרבה יותר אחריות על הקוד שהוא מוציא תחת ידיו, כולל Unit Tests מלאים כמובן, וה-Eco System בכללותו – כלי ה-CI וה-Automatic Deployment דואגים להריץ באופן אוטומטי Integration Tests, Automation Tests וכו', ולצבוע את התהליך באדום אם משהו נכשל. ואחרי ה-Deployment (האוטומטי) מתבצעות בדיקות Production על כל שרת ושרת, שגם הן מתריעות לכל העולם אם יש בעיה. ואתה דוגם מטריקות שונות שמוצגות לך בפלאזמה גדולה באמצע המשרד (ובמטבח, הכי חשוב) שמראות לך אם משהו השתבש מאוד ב-deploy האחרון כך שתוכל לחזור מהר (ובקליק אחד) גירסה אחת אחורה.

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

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

    הגב
  12. GadiM27 בדצמבר 2011 ב 22:12

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

    הגב
  13. ליאור שכטר28 בדצמבר 2011 ב 11:22

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

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

    אני מניח שכולנו מבינים שאין כאן נסיון לשטוח את כל התורה של ניהול ראיון\מבחן. וכולנו לוקחים בחשבון שיש כל מיני פרמטרים להחלטה אם מישהו "עובר" או "לא עובר" ראיון. בינהן, כמו שכבר הסכמנו – הבן אדם היושב מולך.

    הגב
  14. אילן קירשנבאום29 בדצמבר 2011 ב 13:56

    גדי,

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

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

    הגב
  15. GadiM29 בדצמבר 2011 ב 14:39

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

    הגב
  16. אילן קירשנבאום29 בדצמבר 2011 ב 16:29

    לגבי הארכיטקט: אלעד באדיבותו הפנה אותנו למאמר מאלף על אסטרטגיות לחלוקת משימות.
    בדף 2 בסעיף 1.3 יש ציטוט מהספר Zen Mind, Beginner's Mind שאני מעתיק לכאן:
    “In the beginner's mind there are many possibilities,
    but in the expert's there are few.”
    לפעמים השוליה מוצא פיתרון שהמאסטר לא היה חושב עליו. בדרך כלל המאסטר מתקן את השוליה. אבל לא חבל לאבד את החדשנות והיצירתיות של השוליה לטובת הנוחות של המאסטר?

    הגב
  17. GadiM29 בדצמבר 2011 ב 18:12

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

    הגב
  18. pd12 בינואר 2012 ב 21:22

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

    הגב