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

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

מה לWPF וVS2003?

בימים בהם אני עובד בכפיפה אחת עם אנשי MCS (הנפלאים אגב) כדי לאמץ פתרונות לפלטפורמות עתידיות (או במילים אחרות – מחפש דרכים לסבך עוד יותר את העניינים), מרים פרויקטים מבוססי WPF ונמצא בקשר מתחייב עם צוות הפיתוח של המנוע (ולשמחתי, כנראה גם מוצא להם באגים), מנסה להטמיע בפרוייקט ייחודי מנוע של Virtual Earth 5.0 כתשתית שו"ב בטחונית, מנסה ליישם פרויקט ממשקים בין מערכות מודרניות למערכות Legacy באמצעות WF; אני מוצא את עצמי חורש את הרשת בשביל למצוא תיעוד להבדלים בין Visual Studio 2003 לבין Visual Studio 2005 (רשימה מפורטת של ההבדלים אגב תכתב בפוסט הבא שלי).

על ארגונים גדולים, שמהותם אינה תוכנה

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

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

מצבים כאלו למעשה כופים על אנשי התוכנה התנהלות מאוד מיוחדת, לא פולשנית ככל שניתן; מדיניות שלא תטיל חורבן על פרוייקטי Fortran77 על VAX/VMS.

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

עקרון אי הודאות בתשתיות תוכנה

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

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

התוצאות של הצוות היו מדהימות, וכך גם טענו מי שבצעו לו CR וDR ברדמונד, במסגרת הסכם שיתוף פעולה אסטרטגי, אלא שעד שהצוות סיפק תשתיות לפרויקט התוכנו שלשמו הוא הוקם – הפרויקט כבר היה בפיגור של שנה. בתקופה הזאת, המשכנו לבדוק תשתיות. בינתיים הייתה תשתיות OR/M פתוחה בשם AtomsFramework שזכתה לבית חם בפרויקט אחר במפעל; מיקרוסופט לא הפסיקה להזכיר את הObjectSpaces שלה, שלימים הפך לLINQ (או Jasper למהדרין). אבל הכלי הזה, שהיה אמור לראות אור ב2005, רק לפני חודשיים יצא כגרסת בטא במסגרת הCTP Extensions של 3.5.

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

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

ומה עכשיו?

אז הגוף שבו אני נמצא קיבל בשעה טובה החלטה אמיצה לבחון את Visual Studio 2005. בישיבה שכינסנו נשאלנו אובייקטיבית – מה מעבר מ2003 ל2005 ייתן לנו (לא מדובר על מעבר של אפליקציות חדשות, אלא הסבה של אפליקציות שכבר נכתבו ב2003). המסקנה הייתה שלא הרבה. היות ואין טעם לממן פרויקטי הסבה בשביל להשתמש בכל 101 (++) התוספות של הסביבה החדשה, מעבר לתאימות עתידית אין יתרון ברור. מאידך – חסרונות מסתבר שיש (וכפי שכתבתי קודם לכן, רשימה טכנית שלהם תפורט בפוסט הבא שלי.. לא רציתי ללכלך את הפוסט הזה). ובצער רב, בניגוד מוחלט לתפקיד הCTO אותו אני ממלא בבשור – אשר מחייב אותי לשמור על חדשנות ולחקור ולהטמיע טכנולוגיות חדשות כל הזמן, נאלצתי להסכים שאלא אם ימצא שהסביבה החדשה פותרת לנו באגים שקורים בעקבות השימוש בסביבה הישנה – אין טעם לבצע הסבה.

אמרתי, ובאותו זמן קימפלתי את אפליקצית הSilverLight הראשונה שלי.

חומר לפוסטים הבאים בסדרה:

1. האם הייתם נוסעים ברכב שהייתה מייצרת Nike? ארגונים גדולים לא צריכים לפתח תשתיות תוכנה ג'נריות.
2. האם גופים שתוכנה הוא לא עיקרם, צריכים להחזיק ולתחזק גופי תוכנה פנימיים? כן (ולא) לOutsourcing.
3. מתי מגיע השלב שבו צריכים להטיל וטו על טכנולוגיות חדשות בתוך פרויקט? כשלפרויקט יש לו"ז.
4. האם קיים התכניתן שיאמץ קוד שלא הוא כתב? על תשתיות אחידות לצוותים לא אחידים.