Elke kleine wijziging in uw applicatie duurt drie weken? Dit is waarom, en wat u eraan kunt doen

U hebt maar één nieuw veld op een formulier nodig. Of één kolom extra in een rapport. Het team zegt: drie weken. U vraagt waarom, en krijgt een uitleg die u niet begrijpt, maar die serieus klinkt.

En u weet nog dat het in het begin anders was. Het eerste jaar kwamen nieuwe dingen binnen een paar dagen. Het team is niet slechter geworden. Het systeem waarin het werkt wel.

Waarom dit gebeurt: technische schuld

Stel u een huis voor waaraan tien jaar lang zonder plan is bijgebouwd. Elke keer trok iemand haastig een kabel door een muur, omdat dat het snelst ging. Vandaag moet u, om één stopcontact te verplaatsen, drie muren openbreken en hopen dat u in de kamer ernaast niets hebt doorgeknipt.

In software heet dit technische schuld, en die gedraagt zich precies als schuld: elke keer dat iets haastig wordt gedaan, sluit u een lening af. De rente betaalt u bij elke volgende wijziging. Na een paar jaar is de rente hoger dan de lening zelf, en gaat alle ontwikkeling naar aflossing.

In een applicatie ziet dat er zo uit:

• Alles hangt met alles samen. Een wijziging op de ene plek breekt iets op een andere, dus moet elke wijziging overal met de hand worden gecontroleerd.
• Er zijn geen geautomatiseerde tests. Elke wijziging betekent de hele applicatie met de hand testen, en de angst om iets kapot te maken vertraagt alles.
• Dezelfde logica staat op tien plekken gekopieerd. Een wijziging moet tien keer worden gedaan, en één plek wordt altijd vergeten.
• Uitrollen is handwerk en riskant. Dus wordt er zelden uitgerold, in grote pakketten, en iedereen houdt elke keer zijn adem in.
• Maar één persoon kent een deel van het systeem. Alles wat dat deel raakt, wacht op die persoon.
• De technologie is verouderd. Een oude versie van .NET en bibliotheken die niet te upgraden zijn zonder dat al het andere uit elkaar valt.

Hoe u herkent dat het ook uw probleem is

U hoeft geen code te lezen. Het is genoeg om hierop te letten:

• schattingen voor vergelijkbare taken worden steeds groter
• het team zegt over sommige delen van de applicatie “daar komen we niet aan”
• na elke nieuwe versie gaat er iets kapot
• nieuwe ontwikkelaars hebben maanden nodig om zelfstandig te werken
• het antwoord op “waarom duurt het zo lang” is altijd “het is ingewikkeld”

Herkent u er drie of meer, dan ligt het probleem niet bij de mensen maar bij het systeem.

Wat niet helpt

Meer mensen aannemen. Meer mensen in een verward systeem betekent meer mensen die elkaars werk kapotmaken. Fred Brooks schreef het al in 1975 op: wie mensen toevoegt aan een softwareproject dat achterloopt, maakt het nog later. En een goede senior ontwikkelaar vinden duurt sowieso maanden.

Druk op het team. Een team onder druk neemt nog meer shortcuts, en elke shortcut is een nieuwe lening. De schuld groeit sneller.

Alles opnieuw bouwen vanaf nul. Het klinkt als een oplossing, maar het betekent een of twee jaar zonder nieuwe functies, en alles weggooien wat het oude systeem goed doet. Het is zelden de juiste eerste beslissing, zoals we ook hier schreven.

Wat wel helpt

Schuld lost u niet in één keer af, maar in een slimme volgorde:

1. MomentopnameWaar de tijd heen gaat
2. KnelpuntenWat het vaakst verandert
3. VangnetTests en automatisch uitrollen
4. OnderwegElke wijziging laat betere code achter

1. Momentopname. Een onafhankelijke blik op de code en op hoe een wijziging van verzoek naar productie reist. Waar gaat de tijd precies heen: naar code schrijven, testen, wachten, of repareren wat onderweg kapotging?
2. Knelpunten. Niet alles hoeft gerepareerd te worden. Delen waar niemand aan komt, mogen lelijk blijven. Eerst wordt opgeruimd wat het vaakst verandert, want daar wordt elke week rente betaald.
3. Vangnet. Geautomatiseerde tests rond de belangrijkste delen, en uitrollen met één klik. Als het team niet bang is voor wijzigingen, worden wijzigingen vanzelf sneller.
4. Onderweg. Elke nieuwe functie laat de code die ze raakt een beetje beter achter dan ze hem aantrof. De ontwikkeling stopt niet, en de schuld wordt in termijnen afgelost.

De eerste verbeteringen zijn meestal binnen een paar weken zichtbaar, niet jaren, en zonder de ontwikkeling stil te leggen. De beste maatstaf is eenvoudig: hoe lang duurt een typische wijziging, van verzoek tot productie, voor en na?

Hoe wij werken

ProCoding is een .NET-studio uit Split, Kroatië, en het opruimen van systemen die in de loop der jaren traag zijn geworden om aan te werken, is een van de dingen die we het vaakst doen.

We beginnen met een review van de code en het proces, en u krijgt een lijst van knelpunten, gerangschikt naar wat ze u kosten. Daarna ruimen we ze op samen met uw team of in plaats ervan, wat u het beste uitkomt. De eerste stap is een gratis gesprek van 30 minuten waarin we doorlopen hoe één typische wijziging bij u verloopt.