
Eric skyder med skarpt...
Livet er for kort til sendmail.cf og heldigvis kan min gode ven & lusepuster Eric Allman mere end det.
Han har lige skrevet et glimrende stykke i ACM Queue om "Technical Debt"
Teknisk gæld er lidt for hurtige og billige "løsninger" som man kommer til at bøde for senere, men der er mange nuancer af teknisk gæld og man kan ikke bare skære det over en kam.
Min personlige favoritsætning i Erics artikel er "Customers usually buy features, not long-term maintainability"
I rigtig mange tilfælde kan man sætte lighedstegn imellem teknisk gæld og abekast: Udvikleren skærer et hjørne og support er dem der får problemet. Ledelsen skærer af projektplanen, men kræver fuld funktionalitet. osv.
Eric foreslår at man bør holde regnskab med sin tekniske gæld i pengebeløb og derfra og til at kræve at det bliver skrevet ind i årsregnskabet er der ikke ret lang vej.
En af fordelene ved teknisk gæld er at den afskrives 100% når man skrotter et system, men i realiteten ankommer det nye system med en indbygget teknisk gæld fra starten.
Jeg har tidligere plæderet for at vi mangler en IT-Havarikommision og hvis nogen gad og lytte efter, ville teknisk gæld helt sikkert blive en af dens hovedværktøjer i udredningen af skandaler som POLSAG.
Print Erics artikel ud i to kopier, giv din chef den ene og bed ham understrege det vigtige, du understreger det vigtige i den anden kopi. Snak bagefter om hvorfor stregerne ikke matcher.
phk
Poul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (7)
Genialt:
Print Erics artikel ud i to kopier, giv din chef den ene og bed ham understrege det vigtige, du understreger det vigtige i den anden kopi. Snak bagefter om hvorfor stregerne ikke matcher.
Måske skulle man gøre det samme med kravspecifikationer, projektplaner osv.
Teknisk gæld er desværre bare et abstrakt koncept. Det er jo nærmest umuligt at kvantificere.
Det er ikke mere umuligt at kvantificere, end det er at give et estimat, som jo for nogen trods alt er "det endegyldige svar"..
Teknisk gæld er desværre bare et abstrakt koncept. Det er jo nærmest umuligt at kvantificere.
Som en der sidder med hovedet begravet i teknisk gæld hver anden dag, kan jeg forsikre om at begrebet er alt andet end abstrakt, og særdeles virkeligt. Kvantificere? Har du set et modul kodet i skodkode af KarlKoder, i den applikation du vedligeholder for nyligt? You're looking at it baby....
De, der har prøvet at skrive skodkode med dårlig samvittighed, hvilket jeg formoder er stort set alle udviklere, er i stand til at forudsige en vis mængde tekniske gæld.
... Kvantificere? Har du set et modul kodet i skodkode af KarlKoder, i den applikation du vedligeholder for nyligt? You're looking at it baby....
Har du læst noget af artiklen eller skal du bare rante ? Stop med at arbejde på lort hvis du bliver gammelsur af det.
Eric foreslår at man bør holde regnskab med sin tekniske gæld i pengebeløb ...
Og med det i mente nævnte jeg at det er så godt som umuligt at kvantificere. Det er i hvert fald min påstand men du må da gerne komme med et bud. Gerne med en bedre metode end vi pt. bruger til at estimere softwareudvikling med som gerne afviger med 300% til ∞. Og vi kender vel og mærke ikke afvigelsen før man har forsøgt.
Og med det i mente nævnte jeg at det er så godt som umuligt at kvantificere. Det er i hvert fald min påstand men du må da gerne komme med et bud. Gerne med en bedre metode end vi pt. bruger til at estimere softwareudvikling med som gerne afviger med 300% til ∞. Og vi kender vel og mærke ikke afvigelsen før man har forsøgt.
Jeg håber da, at du har oplevet bedre estimater. Det kræver selvfølgelig tilstrækkelig små bidder og en åben og ærlig dialog mellem kunde og leverandør. Men teknisk gæld kan - som al anden udvikling - sagtens estimeres. Det smarte ved teknisk gæld-analogien er at den er nem at få kunden til at forstå. Og efter min erfaring er det helt afgørende at kunden for en forståelse for, at den tekniske gæld skal adresseres - og at det koster at adressere den.

