על העוצמה הטמונה ב"טכנולוגיות משעממות" [דעה]

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

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

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

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

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

מקור: ארה"ב

בעיה של חלוקת-קשב

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

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

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

הקשב שלנו הוא משאב מוגבל. אנו יכולים יכולים להתמקד בנושא אחד לעומק, או בשלשה נושאים במקביל, ולהתעמק רק רבע(~) מכך. למה רבע? כי יש לנו Context Switch יקר [א].


אני חושש, שעבור מהנדסים צעירים בימים אלו, המקבילה של מה שקורס ה"נושאים מתקדמים במערכות היפר-מבוזרות, מתייצבות עצמית, מונחות בינה מלאכותית" היה עבורי - היא בד"כ טכנולוגיות חדשות: Docker, AngularJS, React, Scala, או בקיצור: Just Name It!

הדרך להתבלט, ולהרגיש מומחה, עוברת בשימוש בטכנולוגיה ה"מגניבה הנוכחית": "אני כותב ב Rust", "Go", או "Swift" - הוא סמל סטטוס, נחשק לא פחות מהעבודה היומיומית בשפות עצמן.

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

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

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

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

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

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

איזון הוא לב העניין

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

מבחינה מסוימת, החתירה של מתכנת או צוות בודד בארגון לאמץ טכנולוגיה חדשה משיקולים אישיים הוא Local Optimization שאולי נחמד להם - אך נוגד את האינטרסים של כלל הארגון (ה Global Optimization).

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

מצד שני, לריבוי שפות-תכנות (או ספריות) שבשימוש יש גם בעיות:

• קוד נוטה לא-להעלם: אם שוכחים ממנו - הוא לא באמת נעלם, הוא רק הופך לקוד Legacy בו צריך לבצע תיקונים מדי פעם. בכדי לבצע תיקונים - יש להכיר את שפת התכנות / הספריות שבשימוש ברמה סבירה כלשהי. "טריפ" של החלפת טכנולוגיות תדירה תשאיר אותנו עם גן-חיות של Legacies שיש לתחזק. זה הזמן לעבור מקום עבודה...
• אף אחד מאיתנו הוא לא ליאונרדו דה-וינצ'י (איש אשכולות [ב]) - כלומר: לא ניתן להגיע לרמת מומחיות גבוהה במספר טכנולוגיות בו זמנית. זה או להגיע לשליטה X ב-3 טכנולוגיות, או X/2 ב-5 או 6 טכנולוגיות. יש כאן trade-off ברור.
• חיבור בין טכנולוגיות שונות מציב, פעמים רבות, תקורה.

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

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

תובנה מעניינת ששמעתי בכנס GOTO; Berlin הגיעה מניתוח השימוש בחנויות ספרים מקוונות: לא רק בעולם הטכנולוגיה יש נטייה ללכת אחרי "החדש". הם הראו שגם רוב ספרי הניהול שנמכרים (ניהול - דיסיפלינה שמשתנה לאט) הם מהשנה האחרונה, או השנה שלפניה.

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

לוח פתקיות. לא "מגניב" כמו Mingle או ScrumWise - אבל עובד מצויין, וללא Learning Curve.

אבל...

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

כמה משעשע יהיה מצדי להראות כיצד שפת התכנות החדשה שהמצאתי, FibLang, מייצרת בקלות רבה יותר מכל שפה אחרת בעולם סדרה של מספרי פיבונאצ'י. הנה הקוד שנדרש:

do!

המ..המ, האם יש לכם שפת תכנות טובה יותר מהשפה הזו? בואו נזרוק את פייטון ונעבור כולנו ל FibLang FTW!!!

אנחנו יכולים להיות נבונים יותר, מכדי ללכת שולל אחרי מצגי-שווא שכאלה.


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

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

כנ"ל לגבי Frameworks, בסיסי-נתונים, וכו'.

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

מה עושים?

ניתן לעשות חישוב עלות/תמורה פשוט בכדי לבחון האם אימוץ טכנולוגיה משתלם - וכך לאמץ טכנולוגיות במינון האופטימלי.

הבעיה נעוצה בכך שהבעיה היא לא בעיה חישובית פשוטה, אלא יותר בעיה פסיכולוגית / חברתית. כאשר ממש רוצים לאמץ טכנולוגיה יש טיעונים גנריים שנשמעים משכנעים. למשל:

• "המעבר אולי ייקח שנה-שנתיים - אבל אז נהנה מכל היתרונות שלה למשך כל השנים שלפנינו!" (ולא נחליף טכנולוגיה שוב כעבור שנים בודדות?)
• "אבל <חברה טכנולוגית מצליחה> משתמשת בטכנולוגיה הזו - ותראו לאן הם הגיעו!!" (אולי נדבר כל היום רק אנגלית במשרד, כי בחברה ההיא עושים זאת - ותראו לאן הם הגיעו !!)
• "מתכנתים פשוט לא ירצו לבוא לעבוד פה, בידיעה שאנו עובדים עוד בג'אווה גרסה 1.6 בלבד..." (אבל חידוש טכנולוגיות הוא התרגשות זמנית למפתח - שמתרגלים אליה מהר מאוד. בסוף היתרונות / חסרונות העקרוניים של הארגון הם שיקבעו).

אם הבעיה היא פסיכולוגית / חברתית, אולי ראוי שגם הפתרון יהיה פסיכולוגי / חברתי?

באוניברסיטה אחת ראיתי ששינו את שם קורס ה"מבני נתונים" ל"נושאים מתקדמים באלגוריתמים". ניסיון נחמד.

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

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

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

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

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


אין לי פתרון. אני לא יודע מה אפשר לעשות.
אני החלטתי לכתוב פוסט בנושא - אולי הוא יעזור במשהו :)





----

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

באופן דומה, בני אדם שעוברים בין נושא לנושא יהיו פחות מרוכזים בנושא אליו עברו במשך כמה דקות. נוטים לייחס למוח האנושי context switch של 15 דקות, כלומר: כאשר אנו מחליפים נושא לוקח לנו כרבע שעה להגיע לאותה רמת ריכוז ויעילות שבה היינו בנושא הקודם שבו עסקנו. בממוצע גס - ניתן לומר ש 7 וחצי דקות מזמננו (ממוצע גס בין 0 ל 100% ריכוז) מתבזבזות בכל החלפת נושא. אם אנו עושים 20 דילוגים ביום בין נושאים, הלוך ושוב, בזבזנו שעתיים וחצי של פעילות המוח שלנו ביום הזה.

[ב] שנחשב כמוביל עולמי בד-בבד במספר תחומים, בתקופה בה הוא חי.