3 manieren waarop technische schuld je bedrijf raakt

Als een softwareproject snel af en opgeleverd moet worden terwijl de code nog niet perfect is, neemt je team technische schuld op zich om de deadline te halen. In hun haast om functionaliteit op te leveren, wijken developers soms af van de beste manier van programmeren, of 'vergeten' ze delen van de software te testen of te documenteren. Pak je dat niet aan, dan leiden die kortere routes uiteindelijk tot onverwacht herstelwerk en problemen met beveiliging of stabiliteit, die de winst van snel opleveren weer tenietdoen. Technische schuld vat die afruil samen: kortetermijnwinst van snel leveren tegenover waarde op de lange termijn.

Martin Fowler — auteur, developer en internationaal spreker over softwareontwikkeling — introduceert technische schuld zo:

“In deze metafoor levert het snel en vies aanpakken van dingen ons een technische schuld op, vergelijkbaar met een financiële schuld. Net als bij een financiële schuld betaal je rente over technische schuld, in de vorm van het extra werk dat je in toekomstige ontwikkeling moet doen vanwege die snelle, vieze ontwerpkeuze. We kunnen die rente blijven betalen, of we kunnen aflossen door het snelle, vieze ontwerp te refactoren naar een beter ontwerp. Aflossen kost geld, maar we winnen doordat we in de toekomst minder rente betalen.”

Niet alle schuld is slecht, en als wat technische schuld je bedrijf helpt een groot doel te halen, dan kan die 'rente' het waard zijn. Met verhalen over ondernemers die snel rijk werden door producten haastig uit te brengen, en met vasteprijsprojecten die 'niet zo fraai geschat' waren, hebben veel organisaties besloten dat het risico van technische schuld de moeite waard is. Maar er ontstaan wel degelijk problemen, en wat nu een kleine ergernis lijkt, wordt vaak een groot probleem als je het te lang laat liggen.

Dit zijn drie manieren waarop technische schuld je bedrijf raakt:

Wie de snelle, vieze route neemt om een deadline te halen, slaat als developer misschien de gebruikelijke gang van zaken over: nette, geordende code in een uitgebalanceerde architectuur. De structuur wordt dan rommelig en slecht leesbaar. Erger nog: functionaliteit belandt in het 'verkeerde' deel van het systeem om sneller te kunnen leveren. Zulke ontwerpkeuzes helpen het project op tijd af te krijgen, maar maken het lastig voor andere programmeurs om er later aan te werken. De technische schuld die bij slecht ontwerp hoort, is een backlog aan opruimwerk in de code.

Een niet-helemaal-af product uitbrengen kan een zegen zijn voor je bedrijf, maar het kan ook lastige gevolgen hebben. De technische schuld bij een product met wisselvallige prestaties zit in het oplossen van bugs, systeemcrashes en de tijd van je engineers. Fouten in de code komen soms pas na de release boven water.

Is je engineeringteam veel tijd kwijt aan het doorvoeren van eenvoudige verbeteringen in één stuk code, dan is dat een van de alarmsignalen dat de technische schuld een kritiek punt bereikt heeft. Er is een omslagpunt waarop je team meer tijd besteedt aan het omzeilen van technische schuld dan aan het verbeteren van code of het bouwen van nieuwe features. Loopt je systeem vast door veel verkeer of door een wijziging in de code, dan heb je er zojuist technische schuld bij gekregen om de oorzaak te achterhalen.

Om technische schuld heen werken — de 'rente' betalen — is een belangrijke oorzaak van dalende ontwikkeleffectiviteit. De oplossing bestaat uit twee delen:

1. Meet de balans tussen featurewerk en niet-featurewerk met Agile Analytics van ZEN Software.
2. Verander de engineeringcultuur richting principes als de 'boyscoutregel', waarbij het gevierd wordt om kleine verbeteringen aan te brengen waar je ze maar tegenkomt ('laat de kampeerplek schoner achter dan je hem aantrof').

Technische schuld holt je productiviteit uit en maakt de output steeds trager. Slecht ontworpen code kost je team meer tijd en moeite om te doorgronden en te beheren. Vraag je je team om een eenvoudige verbetering die normaal drie weken zou kosten, dan kan het je verrassen dat het er zes worden en dat andere projecten moeten wachten. Technische schuld vertraagt niet alleen de bouwtijd van je team, maar ook je hele cyclus van productie, test en release. Je vraagt om nieuwe features, maar die wijzigingen voegen nieuwe fouten toe aan de slecht geschreven code en maken het testen voor je QA-team alleen maar lastiger. En als je je uiteindelijk door de code heen hebt gewurmd en klaar bent om uit te brengen, is je team waarschijnlijk gestrest door het uitgelopen schema en loop je hoogstwaarschijnlijk winst mis door de verloren tijd in de markt.

Zoals het gezegde luidt: je krijgt waar je voor betaalt. Gaat het om het benutten van een grote marktkans, dan kan technische schuld aangaan soms de beste keuze zijn. Problemen ontstaan wanneer die schuld uitgroeit tot een kolos die je middelen opslokt. Te veel technische schuld verlaagt de productiviteit en de betrokkenheid van je team. Met Agile Analytics, de op machine learning gebaseerde SaaS-oplossing van ZEN Software, zie je nu de trend van een oplopende Lead Time for Change (LT) en van meer aandacht voor niet-featurewerk dan voorheen. Met Agile Analytics of de geïntegreerde DevOps Accelerator van ZEN Software ziet je organisatie problemen met technische schuld vroeg aankomen en kun je bijsturen voordat je in het drijfzand van 'alleen nog rente betalen' terechtkomt.