Software die uitgebreid kan worden

Elk softwareproject begint snel. De eerste functies zijn in dagen klaar, de tweede reeks in weken, en ergens rond de twintigste kost iets kleins ineens een halve maand. Dat komt zelden door slechtere programmeurs. Het is de rekening van beslissingen die eerder zijn genomen.

Uitbreidbaarheid is geen eigenschap die u later toevoegt. Het is het gevolg van een handvol keuzes, vrijwel allemaal gemaakt in de eerste maanden. Dit artikel gaat over welke keuzes dat zijn en hoe u merkt dat het de verkeerde kant op gaat.

Waar de kosten daadwerkelijk zitten

De bouwtijd van een functie is bijna nooit de grootste kostenpost. Dat is de tijd die het kost om te begrijpen wat er al staat, plus de tijd om zeker te weten dat u niets anders sloopt. Beide groeien met de verstrengeling in het systeem, niet met de hoeveelheid code.

• Dezelfde regel logica staat op drie plaatsen, en niemand weet zeker of ze nog hetzelfde doen.
• Er staan velden in het datamodel die alleen betekenis hebben in combinatie met andere velden, en die combinatie staat nergens beschreven.
• Een schemawijziging raakt zoveel plekken dat er een aparte planning voor nodig is.
• Het team bouwt liever een nieuwe functie naast de bestaande dan de bestaande aan te passen.

Dat laatste signaal is het duidelijkste. Zodra aanpassen enger voelt dan toevoegen, groeit het systeem in oppervlakte in plaats van in diepte, en verdubbelt het onderhoud met elke ronde.

Het datamodel bepaalt de rest

Van alle keuzes in een project is het datamodel het duurst om terug te draaien. Schermen herbouwt u in weken; een verkeerd gemodelleerde relatie zit in migraties, in exports, in koppelingen met andere systemen en in de rapportages waar iemand op stuurt.

De vraag die zich terugbetaalt is niet 'welke velden hebben we nu nodig', maar 'waar praat de organisatie eigenlijk over'. Gaat het intern over een dossier terwijl het systeem alleen losse aanvragen kent, dan bouwt u bij elke nieuwe functie opnieuw het begrip dossier na — telkens net iets anders.

Grenzen die betekenis hebben

Een systeem wordt onderhoudbaar door duidelijke grenzen, niet door veel mappen. Een grens is pas echt als er drie dingen over vaststaan:

• Eén onderdeel is eigenaar van de gegevens erachter. Andere onderdelen lezen via een expliciete route, niet rechtstreeks in de tabel.
• Er is een afspraak over wat erin en eruit gaat, die niet verandert zonder dat dat opvalt.
• De afhankelijkheid loopt één kant op. Twee onderdelen die elkaar allebei nodig hebben, zijn in de praktijk één onderdeel met een muur ertussen.

Deze drie regels zijn belangrijker dan de vraag of iets een aparte service of een aparte map wordt. Een goed afgebakende map is beter onderhoudbaar dan een slecht afgebakende microservice, en aanzienlijk goedkoper om te draaien.

Wanneer u iets uit elkaar haalt

De verleiding om vroeg op te splitsen is groot, want het voelt vooruitziend. In de praktijk is vroeg opsplitsen duur: u legt grenzen vast op een moment dat nog niet duidelijk is waar ze horen te liggen, en verkeerde grenzen zijn lastiger te verplaatsen dan geen grenzen.

Splits pas op wanneer de pijn van bij elkaar houden groter is dan de pijn van uit elkaar halen — en niet eerder, hoe verstandig het ook klinkt.

Concreet: wacht tot twee delen aantoonbaar een ander tempo of een andere belasting hebben. Zolang alles in hetzelfde ritme wijzigt, is één geheel met nette interne grenzen sneller, goedkoper en makkelijker te herstellen wanneer er iets misgaat.

Kort samengevat

Investeer vroeg in het datamodel en in duidelijke interne grenzen, en stel fysiek opsplitsen zo lang mogelijk uit. Voelt aanpassen even veilig als toevoegen, dan is de architectuur in orde — ongeacht hoe die op een plaatje oogt.