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

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

קרדיט תמונה: Shutterstock

קרדיט תמונה: Shutterstock

הפוסט נכתב על ידי ליאור בר און

אני זוכר את הימים שהייתי סטודנט מתלהב, כאילו זה היה לפני עשר שנים (בעצם זה היה לפני 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 או לניתוח הבעיה העסקית – היכן שבד”כ ניתן להשיג את התשואה הריאלית הטובה ביותר.

balance

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

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

מבחינה מסוימת, החתירה של מתכנת או צוות בודד בארגון לאמץ טכנולוגיה חדשה משיקולים אישיים הוא 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.

לוח פתקיות. לא “מגניב” כמו 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 דילוגים ביום בין נושאים, הלוך ושוב, בזבזנו שעתיים וחצי של פעילות המוח שלנו ביום הזה.

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

הפוסט פורסם במקור בבלוג ארכיטקטורת תוכנה. קרדיט תמונה: Boring Tech / Shutterstock.com

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

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

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אורי
Guest

אין מה לעשות, הטכנולוגיה מתקדמת.

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

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

שאגי
Guest

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

מתכנת ווב
Guest

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

גדי
Guest

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

מיקי
Guest

מאמר מצויין.
מחכה למאמר הבא שלך.

שלמה שוורץ
Guest

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

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

מיכאל
Guest
פוסט מעניין! תמיד כיף לשמוע דעה שהולכת נגד הזרם הפופולארי. כמו שציינת הכל בחיים הוא עניין של איזון, אין ספק שלא צריך לאמץ טכנולוגיות חדשות רק על עצם היותם חדשות אבל מצד שני בחלק גדול מהמקרים כאשר טכנולוגיה צוברת באז יש לכך סיבה. כמובן שאפשר לעשות abuse לטכנולוגיה חדשה בדיוק באותו אופן שאנשי מקצועים חלשים עושים טעויות חוזרות גם בטכנולוגיות קלאסיות. לצד טיעונים מעותיים כמו התקורה שבללמוד טכנולוגיה חדשה ולהסב אליה את המערכות העלת נקודות שאני ממש לא מסכים להן: “אבל משתמשת בטכנולוגיה הזו – ותראו לאן הם הגיעו!!” – לדעתי מדובר בטיעון מעולה כאשר אנחנו רואים באופן עקבי יותר… Read more »
שלמה שוורץ
Guest

מסכים במיוחד עם ההערה האחרונה שלך לגבי סקאלה.

אחרי 20 שנה, את עוד מתכנתת...
Guest
אחרי 20 שנה, את עוד מתכנתת...

לסיכום הפוסט תשקיעו בjava ו ++C ואין תוכנה שלא תוכלו לכתוב!!!

אחרי 20 שנה, את עוד מתכנתת...
Guest
אחרי 20 שנה, את עוד מתכנתת...

שלא לדבר על זה שהקוד יחזיק מעמד 15 שנה בקלות- ויהיה קריא להרבה מתכנתים

wpDiscuz

תגיות לכתבה: