3 manieren waarop technische schuld uw bedrijf raakt

Crowd of passengers having fun in a bustling city on a vibrant floor

Published on 8 November 2022 by Arjan Franzen

Wat is technische schuld?

Als een softwareproject snel moet worden afgerond en opgeleverd terwijl de code nog niet op orde is, neemt uw team technische schuld op om de deadline te halen. In de haast om software te leveren, hanteren ontwikkelaars soms suboptimale praktijken of ‘vergeten’ zij delen van de software te testen of te documenteren. Laat u die shortcuts ongemoeid, dan leiden ze uiteindelijk tot onvoorzien herwerk en beveiligings- of stabiliteitsproblemen die het voordeel van snelle levering tenietdoen. Technische schuld vat de afweging samen tussen het korte-termijnvoordeel van snel leveren en langetermijnwaarde.

Martin Fowler, auteur, ontwikkelaar en internationaal spreker over softwareontwikkeling, geeft deze introductie op technische schuld:

“In deze metafoor levert de snelle en rommelige aanpak ons technische schuld op, vergelijkbaar met een financiële schuld. Net als bij een financiële schuld betaalt u rente: extra inspanning in toekomstige ontwikkeling, veroorzaakt door de snelle en rommelige ontwerpkeuze. U kunt die rente blijven betalen, of u lost af door het snelle, rommelige ontwerp te refactoren naar een beter ontwerp. Hoewel aflossen iets kost, verdient u dat later terug door lagere rentebetalingen.”

Niet elke schuld is slecht, en als het opnemen van wat technische schuld uw bedrijf helpt een groot doel te halen, kan de “rentebetaling” het waard zijn. Met succesverhalen over ondernemers die razendsnel producten lanceren en fixed-priceprojecten die ‘iets te optimistisch waren ingeschat’ hebben veel organisaties besloten dat het risico van technische schuld acceptabel is. Maar problemen ontstaan wel, en wat nu onschuldig lijkt, groeit vaak uit tot grote issues als u het te lang laat liggen.

Dit zijn 3 manieren waarop technische schuld uw bedrijf raakt:

1: Geen nieuwe functionaliteit, alleen herwerk

Technische schuld wordt een probleem als zij uit de hand loopt en ontwikkelteams het grootste deel van hun tijd besteden aan het betalen van de “rente” op eerdere projecten, in plaats van te werken aan nieuwe features of cruciale updates. Die schuld moet uiteindelijk worden afgelost, en dat gaat ten koste van het toevoegen van nieuwe functionaliteit of ander werk dat het product vooruitbrengt. Vooruitgang stokt. In plaats van nieuwe wijzigingsverzoeken op te pakken, is het ontwikkelteam uren, dagen, soms weken bezig om quick-and-dirty code zo te temmen dat toekomstige wijzigingen niet pijnlijk zijn of het systeem laten crashen.

Als ontwikkelaars de quick-and-dirty route nemen om een deadline te halen, slaan zij het gebruikelijke protocol over van schone, goed georganiseerde code in een gebalanceerde architectuur. De structuur wordt rommelig en slecht leesbaar. Erger nog: functionaliteit is in het ‘verkeerde’ deel van het systeem gebouwd om sneller te kunnen leveren. Zulke ontwerpkeuzes helpen misschien om op tijd op te leveren, maar maken het later lastig voor andere programmeurs om aan het project te werken. De technische schuld die samenhangt met slecht ontwerp eindigt als backlog met opschoonwerk.

2: Volatiele performance, stabiliteit en security

Een niet-helemaal-af product lanceren kan gunstig uitpakken, maar ook lastige consequenties hebben. De technische schuld die samengaat met een product met volatiele performance draait om het oplossen van bugs, systeemcrashes en de beschikbare engineeringscapaciteit. Bugs in de code kunnen pas na de release aan het licht komen.

Als uw engineeringteam veel tijd kwijt is aan simpele verbeteringen in één module, is dat een van de rode vlaggen dat de technische schuld een kritisch punt heeft bereikt. Er komt een omslagpunt waarop uw team meer tijd besteedt aan workarounds rond de schuld dan aan het verbeteren van code of het bouwen van nieuwe features. Crasht uw systeem door hoge verkeersvolumes of door het bewerken van code, dan voegt u zojuist extra technische schuld toe om de oorzaak te achterhalen.

Werken om technische schuld heen — de ‘rentebetaling’ — is een belangrijke oorzaak van verlies aan ontwikkelrendement. De oplossing is tweeledig.

Meet de balans tussen feature- en non-feature-ontwikkeling met ZEN Software’s Agile Analytics
Verander de engineeringcultuur met concepten als ‘the boy scout rule’, waarbij het wordt gewaardeerd om overal kleine verbeteringen door te voeren ('leave the campsite cleaner than you found it' in boy scout speak)

3: Inzakkende productiviteit

Technische schuld trekt uw productiviteit leeg en vertraagt de output. Slecht ontworpen code kost uw team meer tijd en moeite om te doorgronden en te beheren. Vraagt u om een kleine verbetering die normaal 3 weken zou kosten, dan blijkt het ineens 6 weken te duren en moeten andere projecten wachten. Technische schuld vertraagt niet alleen de bouwtijd, maar ook uw volledige build-test-releasecyclus. U vraagt nieuwe features aan, maar zulke wijzigingen introduceren nieuwe bugs in slecht geschreven code en maken het voor uw QA-team lastiger om te testen. En als u eindelijk klaar bent om te releasen, is het team vermoedelijk gestrest door de uitloop en loopt u waarschijnlijk winst mis door verloren tijd op de markt.

Conclusie en oplossing

Zoals het gezegde luidt: goedkoop is duurkoop. Als er een grote marktkans ligt, kan technische schuld opnemen soms de optimale keuze zijn. Het gaat mis wanneer de schuld sneeuwbalt tot een moloch die uw middelen uitput. Te veel technische schuld verlaagt de productiviteit én betrokkenheid van uw team. Met ZEN Software’s op machine learning en AI gebaseerde SaaS-oplossing Agile Analytics ziet u trends als een lagere Lead Time for Change (LT) en een hogere focus op non-feature-werk dan voorheen. Met Agile Analytics of ZEN Software’s geïntegreerde DevOps Accelerator herkent uw organisatie technische schuld vroeg en kunt u bijsturen voordat u wegzakt in de drijfzandhel van ‘interest-only development’.