קטגוריה: ניהול פרויקטים

כניסה לפרויקט קיים

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

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

התחלה

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

טעויות בכניסה לקוד/פרויקט קיים

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

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

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

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

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

הדרך שלי ללמוד

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

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

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

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

רכיבים קטנים

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

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

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

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

עבור מה השיטה לא מתאימה?

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

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

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

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

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

סליחה, יש לכם אולי זמן ללמוד טכנולוגיה חדשה ?

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

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

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

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

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

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

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

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

אם מסתכלים על הקפיצה הגדולה בין 1.8.6 ל2.1.2 אפשר לחשוב כאילו לא היה מספיק זמן להמיר דברים, אך למעשה המעבר לרובי 2.0.0 היה מאוד ארוך, ובאמצע כלל גרסאות כמו 1.8.7 שהיו הרבה שנים בתמיכה, וגם 1.9 על סדרותיו, שנתנו את האפשרות להתאים את הקוד למעבר של גרסה 2.0.0. כלומר אותו ארגון נתקע מאחור, ועכשיו הקפיצה שלו יקרה מאוד עם המון בעיות, בעוד שאם היה "זורם", העלות הכוללת היתה נמוכה בהרבה, ושורת  הרווח שלו גבוהה יותר.

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

תכנון מודלארי של מערכת

"If I had eight hours to chop down a tree, I'd spend six sharpening my ax." — Abragam Lincoln

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

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

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

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

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

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

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

למשל אפילו הגדרה של "עד שלא מאשרים משהו, אתה משמיע אפשרויות" לקח לי חצי דקה להוסיף למערכת.

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

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

אנטגוניזם מקצועי

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

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

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

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

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

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

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

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

האם מיקרוסופט נעלמת מהעולם העסקי ?

לאחרונה לקוח נפל בכך שהזמין מערכת ממישהו שהקים חברה על איזה קורס וחצי של פיתוח בטכנולוגיות מיקרוסופט שלקח, ואותו אדם לא הצליח לספק לו את מבוקשו.
כאשר הלקוח עוד חשב כי יקבל, ביקש ממני סיוע למצוא שרת אירוח מבוסס Windows, היות והוא היה זקוק להתקין את המערכת שאותה חברה בנתה עבורו.
אז שנינו חיפשנו משהו בסדר גודל מסויים, והמחירים שמצאנו במקרה הטוב התחילו ב50 יורו.
מיקרוסופט Azure עצמה כל כך יקרה ולא ריאלית לעסק קטן, אשר זה נפסל עוד ללא מאמץ.
אז הלקוח הזמין Windows Server 2012. וגילינו כי זה, מגיע עם ממשק של Windows 8 משום מה.
והשאלה הראשונה ששאלתי היא: למה ?

מי ירצה להריץ שרת שעובד קשה על מערכת טאבלט ? מדוע הממשק צריך להיות זהה גם כאשר מדובר בשרת ?

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

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

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

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

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

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

מחדשנות לשמרנות

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

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

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

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

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

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

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

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

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

לימוד שפת רובי

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

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

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

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

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

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

האם יש צורך בQA ?

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

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

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

מי תיקח כמתכנת אצלך ?

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

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

בהרבה פורומים אני רואה את התשובה: "שפות התכנות הנפוצות הן 1,2,3,4 אז תלמד אותן". זו הטעות הכי גדולה לדעתי להגיד למישהו לעשות. היות ומה שנכון כרגע לא בהכרח נכון עוד שנתיים מהיום.
כן ללמוד גם את השפות 1,2,3,4 . הבעיה היא שזה לא "בשלוף", כי צריך להבין mindset של שפה, יותר מאשר את התחביר שלה, וזו כבר פעולה שלוקחת זמן.

אז מה כן אני מייעץ ?

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

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

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

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

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

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

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

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

שימוש שגוי בזמן המתכנת

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

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

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

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

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

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

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

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

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

תובנות השוק מהרצאה שהעברתי

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

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

לאחר מכן, העברתי הרצאה על No(t only) SQL. בהרצאה העברתי הסבר מה זה בגדול אומר, איך מבינים בכלל מתי, ואיך הוא מתאים לנושא, התמקדתי בMongoDB ובRedis. שני מסדי נתונים אשר אני משתמש בהם.

הדגמתי להם לפי צורות העבודה שלהם, כיצד הם יכולים לשפר להם את הביצועים, למנוע בעיות עומסים שונים וכו'

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

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

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

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

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

Facebook do not understand their users

I've been using Facebook on and off since 2007, and have to say one thing:

Facebook do not understand their users, or how to make things right !

What does it mean, you probably ask yourself ?
Well here are some of the messages I keep on getting on Facebook in the past few months (Almost constantly): להמשיך לקרוא

עתיד עולם התכנות לאן ?

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

למשל כאשר אדם שאל שאלה בwhatsup על ללמוד לפתח אפליקציות לאנדרואיד. אנשים התחילו להציע לו ללמוד את שפת C ואת שפת ++C, וכו' … ובסוף אחרי שהבין איך לתכנת בשפות האלו, לעבור לJava אשר איתה הוא סוף כל סוף יגיע "למנוחה ולנחלה".

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

ההבדל בהצעה שלי, הוא בכך שבאמצעות FPC, אני יכול לכתוב אפליקציות טבעיות לאנדרואיד (מהדר אותן לקבצי class של ג'אווה), ויותר מזה, אני יכול גם לבנות מערכות עבור iOS (יש בMarket של אפל, תוכנות שלמות אשר כתובות עם FPC ודלפי החדש עבור iOS), לספק את אותן המערכות לסביבות שולחנות העבודה, web ושרתים. כל זה ללא צורך להחליף שפה או טכנולוגיה, ועדיין לתת מענה רחב יותר מאשר פיתוח רק בשפת ג'אווה או Objective-C. להמשיך לקרוא

אתה יכול לקחת את הגמל עד לבאר, אתה לא יכול להכריח אותו לשתות …

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

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

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

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

הצד האפל של מתודולוגיות פיתוח

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

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

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

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

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

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

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

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

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

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

לכתוב מחדש

Leaning Tower of Pisaהנה שאלה מאוד מטרידה: "למה אף פעם אין זמן לעשות דברים כמו שצריך, אבל תמיד יש זמן לעשות דברים מחדש ?"

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

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

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

אז מדוע אף פעם אין זמן לעשות דברים כמו שצריך, אבל יש זמן לעשות אותם מחדש ?