“If it ain’t broken, don’t fix it”

If it ain't broken

Over het algemeen sta ik bekend als iemand die zijn mening niet onder stoelen of banken schuift. Bij mijn nieuwe werk wordt dat ook wel min of meer van mij verwacht, dus voel ik mij als een vis in het water. Recent hoorde ik binnen een van de projectteams waarin ik betrokken ben de welbekende uitspraak “If it ain’t broken, don’t fix it”. Iets wat in het Nederlands zoiets betekent als: Iets dat niet kapot is, hoef je ook niet te repareren.

In de ICT kan je over het algemeen niet meer aankomen met één specialiteit, maar je moet ook kunnen schakelen naar en met andere disciplines. Wijze mensen hebben het fenomeen ooit T-shaped professional genoemd. Binnen software-ontwikkeling is het nuttig om bijvoorbeeld naast ontwikkelaar (programmeur vind ik zo’n naar woord) enig verstand te hebben van bijvoorbeeld ontwerpen, testen en documenteren.

Nieuw in dat hele verhaal is het nadenken over de in beheer name van een product, al tijdens de ontwikkelfase. Dit hele fenomeen noemt men DevOps, bestaand uit de woorden Development (ontwikkeling) en Operations (beheer). Het grote probleem in ‘het oude denken’ is dat software wordt ontwikkeld en vervolgens over de schutting gegooid wordt naar een beheerteam, samen met alle problemen en (vanuit beheer-oogpunt) onhandigheden.

De opmerking “If it ain’t broken, don’t fix it” is wat mij betreft ook onderdeel van ‘het oude denken’. De kreet wordt namelijk vooral gebruikt als een software-onderdeel wel werkt, maar eigenlijk niet optimaal is. De ontwikkelaar is eigenlijk niet trots op het bouwwerk dat hij heeft gefabriceerd. Echter, omdat het voldoet aan de functionele eisen zal het wel goedgekeurd worden door de aanwezige testers, of goed te keuren door de klant. Daarmee is het gelijk het probleem geworden van het beheerteam, of van de volgende ontwikkelaar, die bij een wijziging weer door deze programmeercode heen mag spitten.

Mijn stelling is daarom: ga bij een stuk programmeercode waar je niet trots op bent te rade wat voor gevolgen dit kan hebben voor de toekomst. Als het iets is dat met een aan zekerheid grenzende waarschijnlijkheid nooit meer veranderd hoeft te worden en waar een eventueel beheerteam ook geen last van heeft: niets aan doen. Is het voorgaande wel het geval, ga dan na of het optimaliseren ‘het waard is’. Dat is sneller dan je denkt. Onderhoud kost namelijk meer geld, ten opzichte van het maken van aanpassingen als de zaak nog warm is. En je houdt er nog een tevreden beheerteam aan over ook.

Stephan Nagel

Stephan Nagel

requirements analist at Ordina
Stephan (1985) is sinds 2007 werkzaam als informatie-analist in de IT. Daarnaast is hij al ruim tien jaar betrokken als communicatie-expert bij IJsselmeervogels.

Meer info: https://www.linkedin.com/in/stephannagel85/
Stephan Nagel
“If it ain’t broken, don’t fix it”

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *