מעולמו של סמנכ"ל מו"פ – המירוץ האין סופי אחרי הגדרת מוצר, חזון הנדסי, איכות, אנשים, תוצאות, עוד תוצאות (...וקצת אמפטיה בדרך)
פוסטים פופולאריים
-
סף דרישות גבוה (מדי?)
23/5/07 | 3295 צפיות
-
לקפוץ מעל תהום שיווקית ולהישאר בחיים!? (ואיך מו"פ קשור לזה...)
13/8/07 | 4083 צפיות
-
דחיפת איכות במעלה הזרם...
19/4/07 | 4140 צפיות
-
מנהל 2.0
6/6/07 | 2187 צפיות
-
על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק ראשון
12/7/07 | 4428 צפיות
-
סיפור אישי על יזמות וארגוני פיתוח גדולים
20/9/07 | 5203 צפיות
פוסטים אחרונים
- סיפור אישי על יזמות וארגוני פיתוח גדולים 20/9/07
- לקפוץ מעל תהום שיווקית ולהישאר בחיים!? (ואיך מו"פ קשור לזה...) 13/8/07
- על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק שני 21/7/07
- על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק ראשון 12/7/07
- ארץ השמש והאיכות העולה - על דמינג ומשנתו 16/6/07
- מנהל 2.0 6/6/07
על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק שני
בפוסט הקודם ניסיתי לנתח את "הייחודיות" העומדת בבסיס מקצוע פיתוח תוכנה וההנחה הרווחת שהוא מתנהג לפי חוקים "מיוחדים" שלא חלים על מקצועות הנדסה אחרים. מסקנת הביניים שאליה הגעתי היא זו: הקושי בהשוואת מקצוע פיתוח התוכנה למקצועות אחרים אינו נובע דווקא מהייחודיות שלו וייחודיות האנשים העוסקים בו, אלא נובע מחוסר בשלותו כמקצוע יחסית למקצועות הנדסיים אחרים. בפוסט זה אמשיך את הניתוח ואנסה לקנח במספר המלצות. בואו נחשוב רגע על מאפייני בעל מקצוע מעולה בכל מקצוע (כמעט) שנבחר. בעל מקצוע מעולה יודע להפעיל את הכלים הרלוונטיים על חומרי הגלם הרלוונטיים בצורה מיומנת תוך שימוש בידע הייחודי שלו (לגבי המגבלות והיכולות שלהם) כדי ליצור תוצאה מועילה ובאיכות גבוהה. דוגמא טריוויאלית: נגר משתמש בפטיש ככלי ובעץ כחומר גלם על מנת ליצור את שולחן האוכל שקנינו לאחרונה בבית (עיצוב יפה, מוצר איכותי ופונקציונליות שמתאימה לצרכינו).אז מהן המקבילות בעולם התוכנה?
שפות תכנות וקומפיילרים הן הכלים העיקריים שלנו, סביבות פיתוח משולבות (IDE) הן דוגמא נוספת. מה עם כלים משלימים כמו NUNIT או FxCop? נכון, גם הם... אז מה הם החומרים כאן? ובכן, רבבות ה-API הזמינים לכותב הת הם הם חומרי הגלם. למשל ADO.NET, GDI+, ASP.NET, Win32 API, ועוד. באמצעותם "מעצב" התוכניתן מוצר ייעודי ע"י חיבור APIs זה לזה והוספת לוגיקה – חישבו כאנלוגיה על מערך צינורות המים הפרוסים בביתכם: הם מחוברים בצורה ייחודית ביניהם ולאביזרי קצה (כמו כיורים, מדיח, מכונת כביסה) כך שבעת הזרמת מים (data) דרכם, יהנה הדייר (המשתמש) מאספקת מים לשתייה ושימושים פונקציונליים נוספים. מה קורה בסיום שלב כתיבת התוכנית? פוף... "נעלמים" הכלים – אין קומפיילרים, NUNIT, וכו'. הלקוח מקבל חומרים המעוצבים ומקושרים באמצעות קוד. זה המוצר המוגמר! אז דיברתי קצת על מה מאפיין בעלי מקצוע באופן כללי ומיפיתי את זה לבעל מקצוע שכותב תוכנה... אבל איפה הבעייה שהזכרתי קודם? הבעייה לראייתי היא שקצב התפתחות הכלים והטכנולוגייה נעשה מהיר יותר ויותר בשנים האחרונות. במקביל המוצרים אותם יש לפתח הולכים ונעשים גדולים ומורכבים. הכלים מפגרים מאחור ביכולתם למדל את אותה מורכבות.. אנחנו נכנסים למירוץ מטורף בלי מנצחים בינתיים... כדי לקבל תחושה על קצבי השינוי, בואו נלך אחורה 20 שנה- ארגז הכלים של תוכניתן היה בסיסי מאד: שפה אחת בסיסית אולי שתיים, IDE בסיסי (במילים אחרות עורך טקסט כמו VI), דיבגר, כלי מעטפת פשוטים מעל מערכת ההפעלה (למשל AWK – איכס). בגיזרת ה-API היה לנו את ה- C library ואולי עוד כמה... היופי היה בפשטות – ידעת שאם השתלטת על מספר קטן של כלים, כבשת את פסגת הר האברסט! אתה מקצוען אמיתי!אבל למה ללכת רחוק אחורה? אפילו לפני 10 שנים, העניינים היו יחסית פשוטים עדיין. תחום השרתים ומיליון שכבות האבסטרקציה בין שרת לקליינט (זוכרים Microsoft DNA?) היה עדיין בחיתוליו... עולם השירותים (services) עדיין היה על הנייר ותחום תכנות הווב באופן כללי היה בשלבים מוקדמים של התפתחות.
מה היום? רובינו קבורים תחת מפולת שלגים גבוהה של כלים וטכנולוגיות היוצאות חדשות לבקרים. רוצים קצת קללות? שימו משקפי מגן שלג קודם: MOM, SOA, XAML, SOAP, VSTO, XQUERY, ORM, GPL, BEPL, ... להמשיך?... זהו רק קמצוץ שלא נדבר על כל הווריאציות של כלים שונים תחת יצרנים שונים ומערכות הפעלה שונות...מה אני מנסה להגיד כאן? קצב השינויים, הסיבוכיות והרוחב של הכלים והטכנולוגיות החדשות גדל באופן אקספוננציאלי ב-20 השנה האחרונות באופן שלא מאפשר לנו לצרוך אותם באופן יעיל בלי לשנות את קהל הצרכנים – אנשי התוכנה. כדי להמחיש עוד זכרו שעבדנו לא פחות קשה לפני 10 ו-20 שנה... הבעיה היא שלא ניתן להגדיל משמעותית את כמות ההשקעה (לפחות בלי להיכנס לתהליך גירושין כואב אחד לפחות בדרך) ומצד שני עלינו לשלוט על כלים וחומרי גלם הגדולים כיום פי 5-10. לכן "הגישה ההירואית" לפיתוח לתוכנה פשוט לא תוכל להמשיך להחזיק מעמד לאורך זמן בלי פגיעה במיומנות ובאיכות התוצאות... אלא אם כן נשנה את הגישה לבעייה... כבר הוכחנו שהתעשייה הזו יודעת לעשות קפיצות משמעותיות לאורך זמן בהינתן הצורך, למשל המעבר מ- client server לגישת שכבות, למשל מעבר מתכנות פרוצדורלי ל-OO, למשל מניהול פרויקטים בגישת מפל מים ל-agile. אז מה מתחילים לעשות (אחרת)? – מתחילים להתמחות!
בכל תעשייה שנבחן נגלה את העיקרון הבא: חלוקה גבוהה של עבודה ועומק יצור מוגבל שכיחים מאד לכל תהליכי הייצור שעומדים מאחורי כמעט על מוצר צריכה בחיינו. דוגמאות? · כמה סוגי מקצועות משתתפים לדעתכם בבניית מכונית? אופנוע שטח? · אני מניח שלכולנו יצא לצפות ברשימת קרדיטים בסוף סרט בורקס ממוצע. מה היה אורכו? כמה מקצועות השתתפו בו?
בואו נחשוב כעת על פרויקט תוכנה ממוצע. כמה מקצועות שונים נאפיין בו? 1,2, 5?... בואו נספור ביחד – אני חושב על "מתכנת UI", "מתכנת מערכת", ו-... רגע!... אמרנו שלא סופרים תפקידים, אלא מקצועות! כאלו שצריך להתמחות בהם ויש ציפיות מוגדרות מהתפוקות בהם. אז בואו ננסה שוב – "project leader", "architect", "programmer", "tester", "production engineer", "technical writer". האבחנה שלי שכמעט כולם צמחו ממקצוע אחד "software developer". מנהל צוות הוא בד"כ מתכנת בכיר, אותו הדבר לגבי ארכיטקט. בודק תוכנה הוא הרבה פעמים מתכנת מתוסכל או כזה שלמד מקצוע כלשהו אחר והמסלול להייטק עבורו עובר דרך בדיקות תוכנה... כנ"ל לגבי production בחלק מהמקרים שאני מכיר.אז בפועל אנו רואים שרוב תפקידי פיתוח תוכנה מאויישים ע"י אנשים שעושים רוטציה. כמו כן אין מקצוע ברור (דרך הכשרה ומדידה) שמשוייך עם כל אחד מהם (פרט לבסיס כלשהוא במדעי המחשב). זה עשוי להישמע סביר בשמיעה ראשונה ומסביר בהחלט את גישת "הכל-יכול" שמשוייכת פעמים רבות עם אנשי תוכנה. כמו שתיארתי בחלק הראשון (הפוסט הקודם) מקצועות התוכנה ניבנו בגישת האומנות ולא ההנדסה. בגישה כזו העיקר סבב סביב פעולות הפיתוח וכתיבת הקוד. Production נגמר בהעתקת כמה קבצים ממקום למקום, QA לא היה חשוב מדי ונעשה כלאחר יד בסוף הפיתוח או אפילו יותר טוב (אלק) – ע"י הלקוח, המוצר יצא כשהרגישו שהוא מוכן (או כשנמאס למתכנתים) וארכיטקטורה התפתחה כמו יצירת חימר בידי האומן... היום כמו שכולנו יודעים, האתגרים השתנו משמעותית – בודק תוכנה צריך ללמוד כלים רבים ומתודולוגיות כדי להיות אפקטיבי בסביבת מוצר מורכב (בדיקות ידניות לא טובות מספיק, קשה לעשות בדיקות טובות בלי הבנת white box, שימוש ב- code coverage, כלים לניתוח תלויות בקוד, כלי אוטומציה, כלי עומסים, וכו'). בדומה לכך תהליכי production טובים דורשים הבנה עמוקה בכלים ותהליכי build, הבנת תהליכים לבניית מעבדות חכמות, וכו'. האתגרים ב- production דורשים נסיון הנדסי ויכולות בניית תוכנה כדי למדל את התהליכים המורכבים ולקשור קצוות בין כלים קיימים לתהליכים באמצעות קוד. המושג "מתכנת" או "איש פיתוח" הוא כוללני מאד ולא מאפשר להבדיל כהלכה בין תתי ההתמחויות לעיל. לפני כשנתיים מיקרוסופט עשתה צעד חשוב קדימה במוצר Visual Studio Team System וחילקה את המוצר לקטגוריות: ארכיטקטים, מפתחים, בודקים, מנהלי פרויקטים, ולאחרונה גם אנשי DB. יחד עם זאת לא ראו צורך לקחת את קטגורית "המפתח" ולפתחה לתתי קטגוריות נוספים... בוודאי תסכימו שמפתח UI שונה ממפתח DB, ששונה ממפתח תמיכה בשפות שונות ששונה ממפתח אבטחה וכו'. נושא ההתמחות בתעשייה שלנו כן קיים באספקט אחר – התמחות אנכית (ורטיקלית). למשל מפתח משחקים בד"כ לא יעבור לפתח קומפיילרים. מפתח אפליקציות מידע לא יעבור לפתח אפליקציות סלולר וכו'. מה חסר לנו? התמחות אופקית! אם מסתכלים על סט דרישות של מוצר ממוצע רואים שחלק גדול מהדרישות הן הדרישות הלא-פונקציונליות שלו (על הפונקציונליות לא מדברים – לוקחים אותן כמובן מאליו!) – למשל האם המוצר עומד בדרישות עומס גבוה, האם הוא scalable, האם הוא גמיש מספיק לשינויים עתידיים, האם קל יהיה לתחזק אותו, וכו'. כל אלו דורשים התמחויות שלא קיימות היום. אילו התמחויות אופקיות עשויות להתפתח בעתיד? הינה מספר קטן של דוגמאות שאני רואה: · מהנדסי user interface – הכרות מעמיקה עם טכנולוגיות וכלים הקשורים לפיתוח ממשק משתמש. הבנת ממשק משתמש web ולא-web. יכולת התאמת ממשק משתמש למשתמשים מסוגים שונים, הכרת יכולות של מערכות הפעלה שונות בהקשר זה, וכו' · מהנדסי אבטחת מידע – בכל מוצר גדול כיום יש שיקולים של אבטחת מידע. האם השרת שבפיתוח חסין להתקפות שונות ואיך למנוע אותן, איך עושים threat modeling למוצר שבפיתוח וסוגרים פרצות אבטחה בשלב מוקדם תוך התאמת ה- design, איך פרצות חדשות המדווחות ע"י המומחים בעולם יכולות להשפיע על המוצר, איך בודקים את חסינות המוצר להתקפות בסוף פיתוחו? · מהנדס בדיקות עומסים וביצועים – תפקידו לבדוק שהמוצר יעבוד היטב בסביבות בהן הוא יעמוד בעומס שימוש רב, לספק ללקוחות מסמכים שיעזרו להם לחשב דרישות חומרה עבור עומסים ספציפיים. בנוסף מומחה ביצועים כזה יעזור לפתח שיטות מדידה למדידת ביצועים שוטפות, יזהה צווארי בקבוק בביצועי המערכת ויעזור לפתור אותן בזמן פיתוח · מהנדס accessibility – תפקידו לתכנן מוצר שיהיה מתאים לשימוש אוכלוסיות שונות של משתמשים שלחלקן יש מוגבלויות שונות · מהנדס DB- תפקידו להבין לעומק DB ושיטות לתיכנותם תוך לקיחת שיקולים שונים כמו availabiliy. הוא אמור להמליץ וליישם שיטות ORM בארגון הפיתוח. הוא המומחה בפיתרון כל בעייה המערבת data replication בין בסיסי נתונים (למשל תכנון תהליך SSIS בסביבת מיקרוסופט) איך התמחות אופקית תשפיע על מסלולי ההכשרה והשוק? מספר נקודות למחשבה: · האקדמיה תצטרך להכניס תתי התמחויות לתוכניות הלימודים במדעי המחשב לאורך זמן - בין אם בתואר ראשון או בתארים מתקדמים. ייתכן שכחלק מזה אף יתווסף שלב סטאז' בדומה למקצועות כמו רפואה · מסלולי הכשרה חיצוניים יתבססו ויוכרו ע"י התעשייה – לימודי תעודה בתתי התמחויות כמו אבטחת תוכנה יתפסו תנופה · נושאים מסויימים בסיסיים כמו בקרת איכות שמאד חסרים בתוכניות הלימודים במדעי המחשב כיום יכנסו לתוכניות הלימודים בצורה אינטגרלית (כולל קורסים תיאורטיים ודגש מעשי כמו UNIT TESTING). תוכנית הלימודים הבסיסית תיהפך למעשית יותר ותכשיר אנשי בדיקות ומהנדסי תוכנה בעלי בסיס טוב יותר שיכולים להמשיך לשלב ההתמחות · שוק העבודה יעבור התמחות. מעסיקים יחפשו פונקציות ספציפיות לפי צרכי הפרויקט כמו "מהנדסי UI" או "מהנדסי DB" ולא "מהנדסי תוכנה מנוסים"... משמעות אפשרית של התמחות היא שמומחים יתנו שרותים בתחומם למחלקות או חברות. אופי העבודה יהיה יותר פרויקטלי ומנגנון הדיווח יהיה מטריציוני. שוק ה-free lancers בתחום זה יתפתח ויפרח מאד. זהו בינתיים. כרגיל אשמח לעורר דיון מעניין בקפה מו"פ. אני מניח שחלק מהדיון השלם לגבי מה צופן לנו העתיד ושלא טופל פה צריך להתמקד בצד הטכנולוגי. אני מזמין אתכם להרים את הכפפה ולשתף אותנו במחשבותיכם...
מה שבטוח – ימשיך להיות לנו מאד מעניין ותזזיתי בתעשיית התוכנה ב-20 השנה הקרובות! אז שנמשיך ליהנות מהדרך ולא רק מהתוצאה... |
תגובות אחרונות
-
דניאל דיין d
בתגובה על על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק ראשון
-
marmor
בתגובה על על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק שני
-
נטע וינריב
בתגובה על סיפור אישי על יזמות וארגוני פיתוח גדולים
-
אבי אהרן
בתגובה על ארגוני מו"פ קלי תנועה – עונת סדנאות ההרזיה בעיצומה!
-
דקל א
בתגובה על לקפוץ מעל תהום שיווקית ולהישאר בחיים!? (ואיך מו"פ קשור לזה...)
-
yassa
בתגובה על הקדמה (והזמנה)
תגובות (15)
נא להתחבר כדי להגיב
התחברות או הרשמה
/null/text_64k_1#
מעניין
עוד על בדיקות תוכנה
שאלה: האם אנחנו עומדים בפני שינוי גדול באיכות פיתוח תוכנה?
תשובה: לדעתי לא בטווח הקרוב.
הסבר: אנו מצויים בתקופה של התפתחות מואצת של אלמנטים שונים, חומרה ותוכנה, שמשפיעים באופן קריטי על פיתוח התוכנה.
בתקופה כזו התמקצעות צרה הינה בעלת ערך לתקופה קצרצרה בלבד, בהתייחס למשך זמן הכשרת מפתח, למשך קריירה של מפתח, ולקצב השינויים בצרכי הלקוחות.
לכן בטווח הקצר אין כדאות כלכלית ואף לא יכולת מעשית להתמקצעות צרה.
שאלה: מה יש לעשות בטווח הקצר?
תשובה: להגדיר נכון ציפיות ויעדים.
הסבר: יש לדרג פרוייקטים שונים על פי שקלול של מספר גורמים:
*קריטיות - מערכת קריטית/לא קריטית
*משך זמן הפיתוח - מערכות שזמן פיתוחן נמדד בחודשים/בשנים
*ערך כלכלי
ככל שחשיבות האיכות, משך זמן הפיתוח והערך הכלכלי גבוהים, כך כדאי ומעשי להשקיע יותר באיכות ובהתמקצעות צרה של העובדים. ולהפך.
לדעתי רעיון זה יש להסביר באופן ברור ביותר גם לסטדנטים וגם לעובדים. סטודנטים - כאשר מלמדים לדוגמה, על יעילות אלגוריתם או על ניצול זיכרון, יש להסביר שבפרוייקטים מסויימים הדבר חשוב יותר ובאחרים פחות. עובדים - כאשר נותנים לעובד או לצוות משימה, יש להסביר בפירוש מהם הציפיות מבחינת איכות הפיתוח.
כל עוד לא מתקיימת הבחנה זו, הרי אנו פוסחים על שתי הסעיפים.
בכל תעשייה שנבחן נגלה את העיקרון הבא: חלוקה גבוהה של עבודה ועומק יצור מוגבל שכיחים מאד לכל תהליכי הייצור שעומדים מאחורי כמעט על מוצר צריכה בחיינו.
דוגמאות?
· כמה סוגי מקצועות משתתפים לדעתכם בבניית מכונית?"
אפשר להסתכל היום על תחום הבדיקות האוטומטיות על מנת לראות את הצומת שהתכנות "הקונבנציונאלי" חצה לפני כ-10-5 שנים.
כמתכנת בדיקות אוטומטיות אני רואה איך גם בתחום הזה כבר לא מספיק להכיר כלי בסיסי אחד על מנת להיות מקצועי. רוחות השינוי מנשבות, ואיתן מגיעה הדרישה להתמחות במספר כלי בדיקה אוטומטיים, וכן בהתמקצעות לבדיקות אוטומטיות של UI לעומת תהליכים פונקציונאליים לעומת תשתיות טכנולוגיות.
זו מגמה מרתקת, והפוסט שכתבת מאיר אותה באור טוב יותר ומאפשר להבין אותה.
אני רק מקווה שבתחום הזה נשכיל לבצע את המעבר להתמקצעות האופקית מהר יותר מ-5-10 השנים שהיו דרושות בתכנות הקונבנציונאלי.
שכן יקר,
אין זילזול בתחומים אחרים, אולם יש משהו חדש ומיוחד בזמן שלנו בתעשיית התוכנה שלא נמצא בתחומי עיסוק אחרים.
אפשר כמובן ללמוד מתעשיית הפלסטיק, ואפילו מהופעת הדפוס והבניין אבל תעשיית התוכנה נוגעת בחומר גלם שונה מזה של התעשיות האחרות כי הוא לא היה קיים בעבר. ה"קוד" מאפשר לנו לעשות ממשקים מורכבים ביותר לכל רמות האנושיות שלנו, אנחנו משכפלים למעשה את היכולות הקוגניטיביות שלנו ומעניקים אותן למכונות.
אני לא חושב שיש חומר גלם גמיש יותר מתוכנה ולמעשה התוכנה מעלה את רמת העיבוד שלנו לדרגה של עיבוד מידע. מידע של זמן אמת כמו גם מידע כללי ניתנים לעיבוד ולשיתוף.
כל זה כמובן לא מבטל את תחומי העיסוק האחרים שלנו, אבל יוצר דופן בזמננו.
עוד משהו על VI:
בילדותי, לפני שהיה לי עורך הפונטים הראשון (פונטוגראפר), כתבתי פונטים ב-Type1 (דיאלקט קשה מאוד של פוסטסקריפט) ע"י VI.
בעזרת פקודות של השפה הבלתי אפשרית הזאת, בניתי וקטורים של כל אות, הינטים, ומה לא. דברים שהיום אני לא אצליח לבצע אפילו עם עורך הפונטים הטוב ביותר (ולא בגלל שהחלדתי, אלא בסך הכל בגלל שכשאתה שולט במה שאתה עושה, תצליח גם עם הכלים הפרימיטיביים ביותר. והיום אני לא שולט בפונטים, אלא בדברים אחרים).
אני זוכר שאתיופים יחפים היו זוכים בריצות מרתון באולימפיאדות, למרות שכל הפרשנים היו בטוחים שהעדר הנעליים יפגע בהם קשות.
ואם כל זה נשמע לכם קשה, אני רוצה להזכיר שפון-נויימן היה מתכנת תוכניות שפת מכונה בעזרת כרטיס מנוקב (אני לא מדבר על אסמבלי, אלא על תוכניות בינאריות!). ובדרך כלל הן עבדו במכה ראשונה.
על ביל גייטס מסתובב סיפור דומה, אמנם לא עם כרטיסים מנוקבים, אבל כן על כתיבת תוכנית בינארית תוך כדי טיסה בדרך לדמו. שם התוכנית: BASIC-Interpreter. וזה עבד במכה ראשונה, בלי דיבאגינג.
אז יחסית אליהם, קטונתי.
קודם כל יש כאן זלזול מסויים בבעלי מקצועות אחרים, פיתוחים טכנולוגיים זה לא המצאה של תעשית התוכנה וגם הנגר היום, אם אתה רוצה ממנו משהו איכותי (אחרת היית קונה מוצר תעשיתי), צריך להשתמש בכלים הרבה יותר מורכבים מפטיש ומסמר (כנס פעם לרשת מטבחים איכותית ותראה איזה פרזולים מטורפים יש שם, איזה חומרים משתמשים ואיזה סוגי גימורים...)
אבל נעזוב את הנקודה הזו.
כמו שאני רואה את זה, השליטה שלך בכלים היא רק 10% מהכישורים שלך כמפתח.
מי ששולט ב 90% האחרים, ילמד להשתמש ב VI תוך שב, להכיר API חדש או כלי חדש לדיבוג.
ההבדל בין הצדדים השונים של כל מקצוע הם עצומים (ההבדל בין מהנדס טנקים למהנדס מארזים הוא הרבה יותר גדול מההבדל בין מפתח GUI למפתח DB או בודק עומס) וברוב המקרים אין תוכנית הכשרה יעודית.
נכון שמהנדס אלקטרוניקה יכול לכוון את עצמו עוד בשלב התואר הראשון להנדסת רכיבים או בקרת מנועים, אבל המסלול ההכשרה מכיל גם את המינימום שנדרש כדי שיוכל בהמשך במאמץ קטן יחסית להפוך למהנדס VLSI .
בתור מפתח התחלתי לעבוד ב VB 5.0 וכתבתי תוכנת התקנה וניהול גירסאות. במקום העבודה השני שלי עבדתי ב VC 6.0 וגם ב driver studio כתבתי ממשק לכרטיס העברת נתונים. בשלישי עברתי לפתח ב Linux וכתבתי מערכת המרבה לאיזשהו בסיס מידע לא סטנדרטי (ואחרי זה הייתי עבד תוכנה) וברביעי שהוא הנוכחי אני מפתח ב Dot Net עוסק ב video streaming ופיתחתי server שמרכז את הפעילות של המערכת שלנו. במקביל, סיימתי תואר שני שבו התמחיתי בלוגיקה הסתברותית.
עד כה בממוצע אני 2-4 שנים בכל מקום סה"כ 10 שנים בתחום ולא צברתי נסיון "טורי" בסביבה או תחום מסויים של יותר מ 3 שנים.
מצד שני אני חושב שהידע שצברתי והבעיות שהתמודדתי איתן במקומות השונים כן תרמו במידה רבה להתמקצעות שלי בתחום הכללי הזה שנקרא תכנות.
קודם כל תודה,
אני נהנה מאוד מהדיון ומהכתיבה שלך.
והאמת גם לי יש געגועים לVI ולEMACS אבל אני מסכים איתך שיש רבים ביננו שנקשרים רגשית לכלים שעובדים עבורם ולא תמיד תורמים לתמונה המערכתית שאתה מנסה להביא כאן.
אם הבנתי נכון, דמות העתיד שאתה מצייר נראית כך:
http://www.lostgarden.com/2006/02/software-developments-evolution.html
במסקנות אני חושב שתמונת העתיד שלי שונה משלך.
התמקצעות היא שלב לפני אינטגרציה. היא מובילה לסטנדרטיזציה שמובילה ל"טכנאות".
כך היום יש סטנדרטים לגודל של שולחן, גודל של דלת ואפילו רוכב מסילת רכבת. הסטנדרטיזציה היא תהליך טבעי במקצועות ומאפשרת "הכלה" של תהליכים במערכות מורכבות יותר.
אנחנו עוברים תהליכי סטנדרטיזציה. הAWK הישן מוכל בPERL שמוכל בPHP וכן הלאה. היום הילדים לא לומדים AWK, הם ישר יוצרים בPHP. הXML הוא כמובן הכלה של שפות תאור ובסיסי נתונים קודמות.
בתהליך הזה חזית ההתפתחות היא שדה פרוץ. מה שאתה מתאר כריבוי שפות הוא בעצם קולות הקרב של התחרות להנציח "סטנדרד" חדש. התחרות נובעת מזה שבתחילה הסטנדרד מאפשר רווחים עצומים לאוחזים בו ובעתיד הרווחים הנובעים ממנו ישאפו לאפס אבל יאפשרו פיתוח סטנדרט שיכיל את הסטנדרד הישן ויפתח "שוק" חדש לתעשיה.
לצד הפיתוחים בתוכנה אנחנו ההתפתחות מלוו בפיתוחים ה"טכנולוגיים" בחומרה. יכולות חישוב והעברת נתונים לצד ארכיטקטורות ביזור מניעות את הדחף לסטנדרטיזציה לעבר רמות הכלה גבוהות שיאפשרו לממש את החלומות הישנים שלנו - קוד בהוראה לפי הנחיות בשפה אנושית שמשרת את כולם.
אני הרבה יותר פסימי לגבי עתיד היי טק הישראלי כמוביל שינויים וחידושים. היגענו למצב שבו אני משווה את בעלי התפקידים בתחום היי טק לסוג הצבא ובעלי התפקידים בו שיצא למלחמת לבנון השניה.
אני חושב שאם לא נעשה שינוי רדיקאלי עמוק בצורת העבודה באופן ההתייחסות לפרט (ללוחם), הרי שנישאר רק עם הפחות טובים (ראה ערך צה"ל).
תמיד רדפנו אחרי סלוגנים, תיתלים במקום אחרי תכנים. כל אחד חושב שה"תייתל" הוא מה שנותן לו את הכוח את הסמכות ולא הידע או היכולת האמיתית של אותו פועל. אנשים פוחדים לקחת לעבודה אנשים מוכשרים כי הם עלולים לסכן את עתידם.
אני טוען כי הסינים, ההודים, ובטח עוד לאומים בעוד כמה שנים יקנו מאיתנו את הידע המצומצם שלנו ויהפכו למרכזי היי טק, על חשבונינו. כפי שויתרנו בעשורים הקודמים על החקלאות, על היהלומים, על הטקסטיל, כך נוותר בשביל רווחתם של כמה מחפשי התעשרות מהירה על היי טק.
לא יהיה היי טק בארץ עד שנת 2017, מי שרוצה להתעשר בזמן הזה מהיי טק שיספור לאחור.
כמו רבים וטובים לפניך, אתה נופל לאותן מלכודות של השוואת תוכנה להנדסה או לכל תעשיה אחרת. אם אתה חושב שהתמקצעות היא מה שחסר בתוכנה, תחשוב מה תעזור לך ההתמקצעות הזו כאשר תצטרך לכתוב תוכנה ל iPhoe לדוגמא. מהנדס ה UI המהולל שלך יצטרך ללמוד כלים חדשים מבית Apple, מהנדס הנגישות שלך יגלה שכל התקנים שיש לו דורשים מסכים גדולים יותר, מהנדס ה DB יהיה מובטל וכל האחרים יקללו את היום שבו זרקו את ספרי ה-++C כי הם מומחים ב .NET.
הבעיה עם מקצוע התוכנה היא שאנחנו מנסים לפתור בעיות יותר ויותר מסובכות - ומצליחים כי יש לנו כלים חדשים בזכות נסיון וחוק מור. משל למה הדבר דומה? לפחח שבונה גג ללול תרנגולות, ואז צריך לבנות גשר, ואז צריך לבנות מעבורת חלל. בעולם ההנדסה הגשר מתמוטט, ואת מעבורת החלל מתכננים אלפי מהנדסים - וגם אז 2 מתרסקות.
בעולם התוכנה, מי שכתב Hello World מצליח לכתוב תוכנת Client-server ולא צריך יותר מקומץ מהנדסים טובים לכתוב תוכנת Web מתקדמת.
הדרך היחידה שאני מכיר להתמקצע, היא לא לשנות טכנולוגיה. בנקים רבים עדיין כותבים ב COBOL. לדוגמא. Java לא השתנתה בהרבה, אלא הוסיפה הרבה JSR עם ממשקים חדשים. אורקל בונה תשתית מבוססת סטנדרטים (Fusion) עם כלי פיתוח נוחים שיאפשרו לעשרות אלפי מתכנתים להתמחות בכלים שלה ולייצר תוכנה מעולה. מיקרוסופט לא מאמינה בסטנדרטים, אבל מנסה ליצור כלים מעולים שיאפשרו התמצקצעות. טעותה הגדולה של מיקרוסופט היא זניחת הכלי הנוח ביותר שהיה להם - Visual Basic ומעבר לשפה חדשה וכלים חדשים.
עכשיו - תגיד לי באמת - בעוד 4 שנים האם תהיה מוכן לגייס מישהו שהתמחה באחד הכלים האלה? כמובן שלא. בעוד 4 תצטרך מישהו שמבין איך לתכנת עבור 8 ליבות, איך לעצב לדגם הטלפון החדש של APPLE שיש לו זיהוי קול ולעבוד עם DB שכוללים OLAP מובנה. כל מי שהתמקצע יהיה פסול עבורך.
אולי עוד 15 שנה יהיה מספיק כוח מיחשוב, כלים ושפות כדי שאפשר יהיה להתמקצע, אבל אז באמת נרגיש כמו פחחים.
נראה שבחברות גדולות כבר הפנימו את הלקח הזה. בדוגמא שלך נתת את MS שמבינים לאן השוק הולך, אני יכול לומר על IBM שחלוקת התפקידים ואפשרויות הקידום ברורים מאוד. יש מסלול לארכיטקטים, מפתחים, אנשי UI ובדיקות - כולם במקביל ולא ברוטציה.
גם בחברות קטנות כבר הבינו את זה, ואם לא הבינו, אז הפנימו. בכל סטארטאפ וובי היום לא מגייסים מתכנתים לעצב UI. ולא לוקחים אנשי תוכנה כדי לתכנן את חוות השרתים.
אפשר להיות בחזית הטכנולוגיה בלי להיות בחזית הכלים.
הכלי החשוב ביותר הוא מה שנמצא בין האזניים שלנו.
והאדיטור הטוב ביותר בעולם הוא זה שהתרגלת אליו.
וחוץ מזה, אני מסכים עם הכל.
שתי התגובות הראשונות התמקדו בהערתי לגבי VI - מי אמר שאין דתות אצלינו במקצוע? חשבתם ש-VI הוא עורך טקסט פשוט?? אז חשבתם... נסו לגרום לאנשי VI לעבור לכלים אחרים, במיוחד בסביבת מיקרוסופט... אולי הפוסט הבא שלי יקרא "הקשר בין אומנות ודת"
אוקי חבר'ה, אני נכנע בזאת וממתן את ההערה לגבי VI בגוף הפוסט.
אלי - אני מסכים שכלים ישנים טובים לא נס ליחם אך אין בכך סתירה למגמות והאתגרים שצויינו. הצורך להישאר בחזית הטכנולוגיה והכלים הוא צורך הכרחי. האתגר הוא באיך עושים זאת ובזה עוסקים שני הפוסטים האחרונים שכתבתי.
אז במקום להכנע למוסכמות, אני ממשיך גם היום להשתמש באותם כלים!
VI הינו עורך הטקסט שלי (גם לעברית - במקומות בהם אני יכול להריץ את התמיכה העברית שלי), וה-C-Library הינה ספריה שאני משתמש בה כל הזמן.
וזה לא מפריע לי לשלב בתוכניות שלי את כל מה שקראת לו "קללות".
אהבתי, הכל נכון, אבל למה ללכלך על ה VI?