„Werkt — niet aankomen” — wat is het, essentie van het principe en risico's

Wat is het principe „werkt — niet aankomen”?

Principe „Werkt — niet aankomen” (Engels: „If it ain't broke, don't fix it”) — is een empirische regel die programmeurs waarschuwt tegen het wijzigen van werkende code zonder voldoende reden. Aan de basis van het principe ligt een eenvoudige statistiek: de overgrote meerderheid van defecten wordt juist geïntroduceerd tijdens het wijzigen van bestaande code.

Het principe is geen dogma — het is eerder een heuristiek die helpt bij het nemen van beslissingen in onzekere omstandigheden. Hoe complexer en rommeliger de codebase, hoe groter de kans dat een „onschuldige” wijziging iets kapot maakt waarvan niemand verwachtte dat het kapot zou gaan.

Volgens onderzoek van Microsoft Corporation (2024) houdt ongeveer 60% van alle kritieke incidenten in productie verband met recente codewijzigingen die met goede bedoelingen zijn doorgevoerd maar niet voldoende zijn getest onder realistische belasting.

Geschiedenis en oorsprong van het principe

Het idioom „If it ain't broke, don't fix it” vindt zijn oorsprong in de Amerikaanse ingenieurscultuur van het midden van de 20e eeuw. Het vroegste gedocumenteerde gebruik wordt toegeschreven aan Bert Lance (1977), die werkte bij de Senaatscommissie voor Financiën van de VS en zich verzette tegen overmatige regelgeving.

In de programmering kwam het principe uit de hardware-engineering, waar het vervangen van een werkende chip door een nieuwe tot onvoorspelbare gevolgen kon leiden. In de context van software kreeg dit principe bijzondere verspreiding met de toenemende complexiteit van softwaresystemen en de opkomst van legacy-code.

Interessant is dat in de programmering het principe ook een keerzijde heeft — „het werkt, maar beter niet aankomen” wordt vaak een excuus om refactoring te weigeren, wat op de lange termijn leidt tot een kritieke ophoping van technische schuld. Volgens het consultancybureau Thoughtworks (2023) heeft ongeveer 40% van de projecten te maken met ernstige problemen door overmatig conservatisme ten aanzien van veranderingen.

Wanneer het principe toepassen

Het principe „Werkt — niet aankomen” is vooral relevant in bepaalde situaties waarin de prijs van een fout het potentiële voordeel van wijzigingen overtreft.

Legacy-projecten zonder tests

In legacy-code die niet door tests wordt gedekt, is elke wijziging een spelletje Russische roulette. Als een programmeur niet kan controleren of de wijziging aangrenzende modules heeft beschadigd, is de beste strategie om werkende code niet aan te raken. Uitzondering — alleen kritieke bugs of beveiligingseisen.

Kritieke systemen

In systemen waar stilstand onaanvaardbaar is of de prijs van een fout enorm is — medische software, avionica, financiële transacties — is het principe „werkt — niet aankomen” de de facto standaard. Elke wijziging doorloopt meerdere fasen van goedkeuring en testen.

Strakke deadlines

Als de release morgen is en de code werkt — probeer dan niet de architectuur te verbeteren. Vervang alleen wat direct van invloed is op de functionaliteit van de release. Stel refactoring uit naar de volgende sprint (maar vergeet het niet).

Risico's van het volgen van het principe

Blindelings volgen van het principe „werkt — niet aankomen” brengt niet minder risico's met zich mee dan eindeloze refactoring. Laten we de belangrijkste gevaren bekijken.

Ophoping van technische schuld

Als elke programmeur dit principe hanteert, verandert de codebase snel in een „gelaagde taart” van verouderde oplossingen, krukken en suboptimale algoritmen. Vroeg of laat wordt de technische schuld ondraaglijk — elke wijziging vereist weken van analyse.

Gemiste optimalisatie

Soms blijkt een wijziging die riskant lijkt, de prestaties of beveiliging aanzienlijk te verbeteren. Het principe „werkt — niet aankomen” mag wijzigingen die meetbaar voordeel opleveren — serverkosten verlagen, pagina's sneller laden, beveiliging verhogen — niet blokkeren.

Verlies van competenties

Wanneer het team jarenlang bepaalde delen van de code niet aanraakt, verliest het het begrip van hoe ze werken. De belangrijkste programmeur vertrekt — en de code verandert in legacy zonder onderhoudsmogelijkheid. Het principe moet worden toegepast met het oog op langdurig onderhoud van het project.

Gulden middenweg: refactoring zonder fanatisme

De optimale strategie — volg het principe niet blindelings, maar pas het bewust toe, rekening houdend met de context. Refactoring is nodig, maar moet veilig zijn.

De padvindersregel

De padvindersregel in programmeren: „Laat de code schoner achter dan je hem hebt aangetroffen”. Als een programmeur een wijziging in een module aanbrengt, moet hij de structuur verbeteren, maar binnen redelijke grenzen. Niet alles herschrijven, maar in ieder geval onleesbare variabelen hernoemen en commentaar toevoegen.

Refactoring onder bescherming van tests

Tests — de enige manier om het principe „werkt — niet aankomen” veilig toe te passen. Als code door tests wordt gedekt, wordt elke refactoring voorspelbaar: de programmeur wijzigt de code, voert de tests uit en ziet of er iets kapot is gegaan. Zonder tests — niet aankomen. Met tests — refactor met vertrouwen.

// Voorbeeld: veilige refactoring onder testdekking
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Oude maar werkende code
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test die beschermt tegen regressie
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Dit voorbeeld toont de juiste aanpak: eerst de test, dan refactoring. Als de test slaagt — is de wijziging veilig. Het principe „werkt — niet aankomen” transformeert in „werkt onder tests — refactor moedig”.

Echte voorbeelden uit de praktijk

Laten we echte scenario's bekijken waarin het principe „werkt — niet aankomen” zowel reddend als destructief bleek.

Reddend geval: Y2K-achtig probleem

Een programmeur ontdekte dat in de code voor datumverwerking het formaat DD/MM/YY werd gebruikt in plaats van YYYY. De code werkte correct van 2000 tot 2025. Ondanks de wens om het te „repareren” — liet hij de code zoals hij was, beperkt tot een opmerking. In 2026 updatete het bedrijf het systeem en de nieuwe oplossing verwerkte eeuwen al correct. Een voortijdige wijziging zou de werkende logica hebben verbroken.

Destructief geval: gegevensverlies door „verbetering”

Een ingenieur besloot de oude maar werkende code voor gegevensimport te „verbeteren” door deze te vervangen door een moderne bibliotheek. Hij hield er geen rekening mee dat de oude bibliotheek een specifiek randgeval behandelde dat niet gedocumenteerd was. Na de release — massaal gegevensverlies. Het principe „werkt — niet aankomen” werd geschonden en de prijs van de fout was twee weken teamwerk voor herstel.