Software Architecture Costs and Benefits
Infinite Velocity zorgt dat je nieuwe softwareversies levert als een continue stroom in plaats van langdurige releases. Om Infinite Velocity te bereiken heb je een moderne cloud-based software architectuur nodig, die het ontwikkelteam continu refactort.
Refactoren is het up-to-date houden door continu actualiseren van de architectuur. In de praktijk is er vaak te weinig tijd voor het refactoren, omdat de vraag naar feature ontwikkeling hoog is. Dat tijdgebrek leidt tot technical-debt, ook wel ‘cruft’ genoemd.
De vragen die ik in deze blog centraal stel:
- Wat is cruft?
- Wat zijn de gevolgen van cruft?
- Wat zijn de costs and benefits van refactoren?
Auteur:
<Krachten die software architectuur beïnvloeden >
Het behoud van een goede software architectuur over langere tijd is niet gemakkelijk. Er zijn meerdere krachten die het refactoren beïnvloeden. Features ontwikkelen zich continu, de onderliggende infrastructuur wijzigt en vragende partijen willen nieuwe functionaliteit zo snel mogelijk hebben. Als er te weinig tijd genomen wordt voor refactoren leiden deze krachten tot zogeheten ‘cruft’ of technical debt, waardoor features juist steeds minder snel beschikbaar komen, in plaats van sneller.
<Softwareontwikkelaar als brandweer>
Als je een feature zo snel mogelijk wilt hebben, dan is de snelste manier om alle standaarden overboord te gooien, het direct te ontwikkelen en te releasen. Maar dat lukt je alleen in een overzichtelijke software architectuur. Dat betekent dat het negeren van software-architectuur maar korte tijd voordelen oplevert. Hoe meer features het ontwikkelteam snel ‘in elkaar hackt’ hoe onoverzichtelijker de architectuur wordt en hoe langer het duurt om de volgende features te ontwikkelen.
Een metafoor van het snel realiseren van een feature is de brandweerauto die met loeiende sirenes naar de brand toe rijdt. Alles en iedereen moet wijken. De brandweerauto komt zo het snelst op bestemming. Maar wat nu als er heel veel brandweerauto’s tegelijk naar verschillende bestemmingen rijden? Dan is het voor elkaar wijken de standaard geworden, loopt het verkeer vast en komt niemand meer op bestemming.
<Hoe lang kun je refactoring achterwege laten?>
Hoe lang gaat het goed om refactoring achterwege te laten? Zoals in de vorige paragraaf staat zullen de de eerste features sneller in productie staan. Naarmate de tijd vordert zal het steeds langzamer gaan.
Onderstaande grafiek laat voor beide gevallen zien hoe de productiviteit zich ontwikkelt in de tijd. De groene lijn is de situatie waarbij software architectuur continu wordt gerefactord en de blauwe lijn waarbij je gestaag cruft opbouwt. Links van de stippellijn ontwikkel je meer features in dezelfde tijd, maar rechts van de stippellijn is dit voordeel weg en zal cruft een steeds grotere rem op productiviteit vormen.
<Wanneer zijn de baten hoger dan de kosten?>
De ervaring leert dat de baten al snel opwegen tegen de kosten. Afhankelijk van het aantal commits, bereik je het omslagpunt eerder na weken, dan na maanden. De opbouw van cruft is alleen te rechtvaardigen in gevallen waarbij op zeer korte termijn een feature nodig is, waarna je de cruft meteen wegwerkt. In alle andere gevallen kies je voor continu refactoren en behoud van je software architectuur.
<Waarom refactoren zo belangrijk is>
Maar waarom is refactoren van software-architectuur zo belangrijk? Dat komt doordat softwareontwikkeling een zeer kennisinitensief vak is, waarbij het grootste deel van de informatie over de code in de code zelf staat. Code is dus niet alleen code, maar ook informerend aan ontwikkelaars over wat de code doet en hoe het is opgebouwd. Daarbij is voorspelbaarheid en logica zeer belangrijk om het geheel te begrijpen en features snel te ontwikkelen.
Slecht ontwikkelde code begrijpt vaak wel degene die het bouwt, maar niet de collega ontwikkelaars. Ze zullen vragen stellen, zoeken en veel tijd besteden het vinden van de juiste oplossing, omdat ze de code niet begrijpen. Ze herkennen de architectuurprincipes niet meer.
Uiteindelijk eindig je met software-spaghetti. Geen enkel teamlid weet dan meer waar hij moet beginnen voor het ontwikkelen van nieuwe features en wat je onderuit trekt bij een change.
<Richtlijnen voor het minimaliseren van Cruft>
- Logical naming – Namen van variabelen en methoden spreken voor zich.
- Onion architecture – Hogere lagen in de architectuur ‘kennen’ de lagere laag en niet andersom.
- Domain Centric Architecture – De architectuur is gecentreerd rondom business domeinen.
- Vertical Slicing – Loosely-coupled verticale architectuur stacks.
- Clean Architecture – Hanteer een afgesproken set met architectuurprincipes.
- Backlog Management – Integreer refactoring in de ontwikkeling van features.
- Peer reviews – Voer regelmatig een peer-review uit op de architectuur.
<Conclusie en meer weten?>
Het gebrek aan behoud van je software architectuur leidt tot snelle opbouw van cruft. Deze cruft vertraagt de ontwikkeling van features. Elk team, ook een topteam, produceert cruft, maar door behoud van softwarekwaliteit, houd je cruft onder controle. Met lage cruft voeg je als softwareteam features toe met minder effort, tijd en kosten.
Behoud van software-architectuur is randvoorwaardelijk om Infinite Velocity te realiseren. Wil je meer weten over Infinite Velocity en over alle factoren om Infinite Velocity te bereiken? Download dan onze whitepaper Infinite Velocity!