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 Kamps billede
Poul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.

Kommentarer (7)

Brian Jacobsen

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.

Lars Bjerregaard

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....

Johannes Ulfkjær Jensen

... 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.

Thomas Christensen

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.

Log ind eller opret en konto for at skrive kommentarer

IT Businesses