Όταν μιλάμε για technical debt, η πρώτη εικόνα που έρχεται συνήθως στο μυαλό είναι παλιός κώδικας, ξεπερασμένες βιβλιοθήκες, πρόχειρα patches και αρχιτεκτονικές που χρειάζονται refactoring. Είναι μια σωστή εικόνα, αλλά όχι ολόκληρη. Γιατί πολλές φορές το μεγαλύτερο τεχνολογικό χρέος μιας επιχείρησης δεν δημιουργήθηκε από έναν developer που έγραψε κακό κώδικα. Δημιουργήθηκε σε μια αίθουσα συσκέψεων, όταν κάποιος είπε «ας το αφήσουμε για αργότερα».
Ο Cunningham (1992), όταν εισήγαγε τη μεταφορά του technical debt, περιέγραψε ουσιαστικά έναν συμβιβασμό. Αποδεχόμαστε σήμερα μια λιγότερο ιδανική λύση για να κερδίσουμε ταχύτητα, γνωρίζοντας ότι κάποια στιγμή θα πρέπει να πληρώσουμε το κόστος. Το πρόβλημα αρχίζει όταν το προσωρινό γίνεται μόνιμο. Και ακόμη περισσότερο όταν κανείς δεν θυμάται πλέον ότι υπήρξε ποτέ απόφαση να διορθωθεί.
Μια επιχείρηση, για παράδειγμα, αποφασίζει να μην αντικαταστήσει ένα παλιό interface μεταξύ δύο κρίσιμων συστημάτων επειδή «λειτουργεί ακόμη». Πέντε χρόνια αργότερα, δέκα νέες εφαρμογές εξαρτώνται από αυτό. Η αντικατάστασή του δεν είναι πλέον ένα μικρό τεχνικό έργο αλλά επιχειρησιακός κίνδυνος. Το χρέος δεν δημιουργήθηκε επειδή το interface ήταν κακό. Δημιουργήθηκε επειδή η απόφαση για τον εκσυγχρονισμό του αναβαλλόταν συστηματικά.
Το ίδιο συμβαίνει με databases που κανείς δεν τολμά να αλλάξει, APIs που σχεδιάστηκαν ως προσωρινά αλλά έγιναν εταιρικό standard, manual διαδικασίες που παρέμειναν επειδή η αυτοματοποίησή τους «δεν είχε αρκετό ROI», ή συστήματα στα οποία μόνο δύο άνθρωποι γνωρίζουν πραγματικά πώς λειτουργούν. Η βιβλιογραφία έχει πλέον διευρύνει σημαντικά την αρχική έννοια του technical debt, αναγνωρίζοντας χρέος στην αρχιτεκτονική, στον σχεδιασμό, στα requirements, στις δοκιμές και στην τεκμηρίωση (Tom, Aurum and Vidgen, 2013· Li, Avgeriou and Liang, 2015).
Υπάρχει όμως και κάτι βαθύτερο. Το decision debt. Κάθε φορά που μια αναγκαία απόφαση μετατίθεται χωρίς συγκεκριμένο σχέδιο επανεξέτασης, δεν αγοράζουμε απλώς χρόνο. Δανειζόμαστε από το μέλλον. Και το μέλλον χρεώνει τόκο.
Αυτός ο τόκος εμφανίζεται ως μεγαλύτερο κόστος αλλαγής, περισσότερο integration complexity, αυξημένος operational risk και μικρότερη δυνατότητα καινοτομίας. Ένα legacy σύστημα μπορεί να λειτουργεί άψογα και παρ' όλα αυτά να αποτελεί στρατηγικό περιορισμό, επειδή ολόκληρος ο οργανισμός έχει προσαρμοστεί γύρω από τους περιορισμούς του. Το technical debt τότε παύει να είναι θέμα της IT Διεύθυνσης. Γίνεται θέμα διοίκησης.
Το ίδιο γίνεται σήμερα ιδιαίτερα εμφανές με το AI. Πολλές επιχειρήσεις ανακαλύπτουν ότι το εμπόδιο για την αξιοποίησή της δεν είναι η έλλειψη ενός καλύτερου μοντέλου. Είναι δεδομένα κλειδωμένα σε παλιά συστήματα, μη τεκμηριωμένα APIs, ασυνεπείς διαδικασίες και αρχιτεκτονικές που σχεδιάστηκαν για έναν κόσμο πολύ διαφορετικό από τον σημερινό.
Το κρίσιμο ερώτημα λοιπόν δεν είναι «πόσο technical debt έχουμε;». Είναι, ποιες αποφάσεις γνωρίζουμε ότι πρέπει να πάρουμε σήμερα και εξακολουθούμε να τις μεταφέρουμε στο αύριο;
Γιατί κάποτε το αύριο φτάνει. Και τότε ο λογαριασμός δεν πληρώνεται μόνο σε γραμμές κώδικα. Πληρώνεται σε χρόνο, ευελιξία, χαμένες ευκαιρίες και στρατηγικές επιλογές που πλέον δεν μπορούμε να κάνουμε.
Βιβλιογραφία
- Brown, N., Cai, Y., Guo, Y., Kazman, R., Kim, M., Kruchten, P., Lim, E., MacCormack, A., Nord, R., Ozkaya, I., Sangwan, R., Seaman, C., Sullivan, K. and Zazworka, N. (2010) ‘Managing Technical Debt in Software-Reliant Systems’, Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research, pp. 47–52.
- Cunningham, W. (1992) ‘The WyCash Portfolio Management System’, Proceedings of OOPSLA ’92. New York: ACM, pp. 29–30.
- Kruchten, P., Nord, R.L. and Ozkaya, I. (2012) ‘Technical Debt: From Metaphor to Theory and Practice’, IEEE Software, 29(6), pp. 18–21.
- Li, Z., Avgeriou, P. and Liang, P. (2015) ‘A systematic mapping study on technical debt and its management’, Journal of Systems and Software, 101, pp. 193–220.
- Tom, E., Aurum, A. and Vidgen, R. (2013) ‘An exploration of technical debt’, Journal of Systems and Software, 86(6), pp. 1498–1516.
