• בלוג
  • אילוצים לא טכנולוגיים

אילוצים לא טכנולוגיים

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

לפני כמה שנים יצא לי לעבוד על רצף של פרויקטים שכל תכליתם היתה תרגום מערכות: תרגום מ perl ל python; תרגום מ Silverlight ל JavaScript, מ jQuery ל React ואפילו תרגום מ Rails ל Node.JS. בכל המקרים האילוצים שהביאו את הלקוחות לתרגום לא היו אילוצים טכנולוגיים.

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

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

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

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