כושר פרעון של דילוור התוכנה וריבית של חוב טכני
התוכנה מידרדרת עם הזמן בגלל קיצורים מסורבלים, שינויים ואי הבנה של דרישות, אי התאמה ואי הבנה של ארכיטקטורה טכנית, כמו גם שינויים בסביבות עסקיות וטכנולוגיות ● מה עושים?
בפיתוח תוכנה יש משמעות רבה לחוב, פשיטת רגל וכושר פרעון – בדיוק כמו בעולם הפיננסי. כושר הפרעון של דילוור הוא היכולת של מחלקת ה-IT לדלוור פתרונות עובדים, שמגשימים צורך עסקי מבעוד מועד. מצד שני, תוכנית Obamacare היא דוגמה לפשיטת רגל.
התוכנה מידרדרת עם הזמן בגלל קיצורים מסורבלים, שינויים ואי הבנה של דרישות, אי התאמה ואי הבנה של ארכיטקטורה טכנית, כמו גם שינויים בסביבות עסקיות וטכנולוגיות. הידרדרות זאת מתרחשת באופן טבעי וגורמת לפשיטת רגל של הדילוור. הקוד הירוד הופך כל כך מסובך ושביר עד כדי כך שכל ניסיון לשנותו הוא מאוד יקר, מסובך לתחזוקה וכמעט שלא ניתן לשינוי. Legacy היא דוגמה אחת לפשיטת רגל טכנית, אבל יש עוד הרבה דוגמאות כאלה לפני שהקוד הופך ל-Legacy.
חוב טכני מתאר את העלויות שהצטברו בגלל הידרדרות הקוד והדרך המקובלת להחזיר את אותו החוב היא לארגן קוד מחדש. ארגון קוד מחדש (Refactoring) הוא פעולה של עיצוב קוד מחדש כך שהממשק והפונקציונליות נשארים זהים, אבל המבנה הפנימי משופר וחסון. כתוצאה מכך, הפונקציונליות והממשק עומדים בדרישות הנוכחיות ומכינים תשתיות לעבודה מהירה.
בהיבט הפיננסי, חלק מהחובות מסוכנים ויקרים יותר למלווה. בדרך כלל, הלוואות ניתנות לאנשים שיש להם קושי בשמירה על לוח סילוקין. סוג מקביל לחוב הוא ״חוב דילוור״ – למעשה, בעיות בקוד או ארכיטקטורה (כלומר, חוב טכני), שמשפיעות לרעה על דילוור יותר מאשר על הפונקציונליות. מאחר שדילוור הוא הרהור שני ברוב הארגונים (מה ש-DevOps מנסה לתקן), רוב ארגוני הפיתוח שמחים לקחת קיצורי דרך ביחס ל-״דילווריות״ של הקוד שלהם. הם משאירים לצוות התפעול לפתור את התקלות – ואין זה בלתי רגיל שצוות התפעול צריך לעבוד סביב אותם באגים בשביל שחרורים מרובים. סוג זה של חוב סאבפריים גורם לקוד להידרדר ולפשוט רגל במהירות רבה יותר מחוב רגיל.
SMS כדוגמה
הנה דוגמה לחוב טכני הגורם לפשיטת רגל של התוכנה: חברת טלקומוניקציה רצתה להשיק תשלום מראש עבור חבילות SMS. בפועל, הארכיטקטורה של מערכת החיוב הניחה שה-SMS הוא חלק מהחיוב הרגיל. נדרשו חודשים לשינוי הארכיטקטורה והקוד כדי לאפשר תשלום מראש עבור חבילת SMS. בינתיים, המתחרים המשיכו לשווק את חבילות המסרונים, הצליחו לגנוב חלק ניכר של הלקוחות ולחזק את מצבם בשוק.
פיתוח תוכנה זמיש ופיתוח מונחה בדיקות יכולים להיות פרדיגמות פיתוח תוכנה שימושיות, אך הם עלולים גם לגרום לכושר פרעון תוכנה מוחלש ויכולים לעודד פיתוח של מוצרי תוכנה שמחייבים הלוואות סאבפריים.
תגובות
(0)