Op deze schoenen liep ik alweer een aantal jaartjes geleden de marathon van Amsterdam.
Een marathon lopen? Gaaf!
Ruim 42km hardlopen, dat klinkt als waanzinnig en vele schrikken er voor terug. Toch vind ik het prachtig om te zien. Ik was aan de buis gekluisterd toen Sifan Hassan op de olympische spelen de marathon won. Later dit jaar, was ik bij de volledige Triathlon van Almere (tevens het EK) en mijn favoriete onderdeel? De marathon natuurlijk! Het is zo geweldig om te zien hoe mensen hem lopen. De opbouw, het afzien maar ook het lekker soepeltjes doorlopen alsof het geen moeite kost.
Het geheim van een goede marathon is zowel heel simpel alsook heel moeilijk: de opbouw. Je moet vooral niet te hard van start gaan en dat is meteen een paradoxaal gevoel. Je bent op dat moment waarschijnlijk op je aller-aller fitst (anders had je geen marathon kunnen lopen ;-).)
Je voelt je super fit en het startschot klinkt en dan mag je eindelijk los! Al die energie al die kracht die je voelt in je eigen lichaam. Maar als je niet op let, ben je al heel snel klaar om een goede tijd te lopen omdat je al die energie meteen gebruikt in de eerste fase.
Als je een goede tijd wil lopen op de marathon, wil je hem “zo vlak mogelijk” lopen. Daarmee wordt het verval in tempo bedoeld. Ga je met een te hoog tempo van start, dan ga je naarmate de marathon vordert, steeds langzamer en langzamer lopen. Weet je echter de eerste helft en de tweede helft in dezelfde tijd te lopen, dan ga je zeer waarschijnlijk een mooie tijd neer zetten. Niet te hard van start gaan is dus kritisch voor een marathon.
(legacy) software en marathons?
Als je kijkt naar software ontwikkeling, kunnen wij als IT engineers leren van het lopen van een marathon. Als het over software ontwikkeling gaat, leren we vanuit opleidingen of vanuit boeken weinig over hoe je om moet gaan met software voor de lange termijn. Met lange termijn bedoel ik meerdere decennia. Ga je zoeken naar research papers, dan kom je er ook bekaaid af. Datgene dat we denken te weten over goed onderhoudbare software houdt niet vaak stand. Denk bijvoorbeeld eens aan Design Patterns. Die waren 20 jaar geleden de hype maar tegenwoordig praten we vaker over anti-patterns.
Hoe voorkom je dan dat je software legacy wordt?
Het is direct belangrijk om te vermelden dat Legacy iets goeds is. Software kan alleen maar legacy worden als het succesvol wordt gebruikt. Legacy heeft ook een negatieve bijklank en dan gaat het vaak over zaken als oudere technieken zoals programmeer talen, middleware en ook hardware, slechte documentatie, hoge complexiteit en moeilijk onderhoudbaar.
Aan een aantal zaken kan je echter wel degelijk wat doen en daar kan je ook de parallellen trekken met het lopen van een marathon.
1 Denk lange termijn
Beschouw een software ontwikkel traject als een marathon. Een marathon kan op je opdelen in 2 halve marathons. Flauw. De eerste halve marathon van je software ontwikkel project is het neerzetten van de eerste versie die in productie gebruikt wordt door echte eindklanten. Als je te hard van stapel loopt, te snel wil, dan begin je met allerlei problemen en uitdagingen in productie waar je focus op moet leggen. Hierdoor raak je je momentum kwijt en vertraag je over de tweede fase.
2 Hou je aan het plan
Als je een marathon gaat lopen onder begeleiding van een trainer, krijg je waarschijnlijk ook hulp bij het lopen van de marathon; een plan. Dat kan bestaan uit blokken die je moet lopen met een bepaald tempo of hartslag. Daarnaast krijg je misschien ook een voeding- en drink plan. Zelfs een kleding advies kan onderdeel zijn van de plannen. Dit soort plannen helpen je om de marathon uit te lopen.
Kijk je naar software ontwikkeling, dan zijn in de eerste fase van een project vaak architecten betrokken die denken aan de lange termijn van een oplossing. Dat vertaalt zich in ontwerp keuzes en richtlijnen die engineers kunnen gebruiken om volgens de ontwerp visie te kunnen door ontwikkelen. Wijk je daar vanaf dan kan het betekenen dat je hier later spijt van krijgt. Details doen er toe en op het moment dat je daar van afwijkt, kan je de gevolgen op de lange termijn niet goed overzien.
3 ff snel bestaat niet
Deze kent elke software engineer wel. Iets “ff snel” doen, gaat altijd pijn doen. Even een patch of een quick fix en dan maanden of zelfs jaren later is het een etterende zweer geworden in de software waarvan niemand meer weet waarom die er is maar waar iedereen vandaan wil blijven.
Tijdens het lopen van een marathon is het daarom slim om je te houden aan een steady tempo en pas helemaal aan het einde, als je je nog steeds “goed voelt”, pas een versnelling in te zetten. Omdat je dan weet dat je na de finish je niet meer hoeft in te spannen.
Wat is die finish in de software ontwikkeling? De afgeronde uitfasering natuurlijk.
4 Kwaliteit doet er toe
Ga je een marathon lopen, dan heb je natuurlijk een paar goede schoenen nodig waarmee je geen blaren oploopt.
Dat geldt ook in de software ontwikkeling. Als je concessies doet aan kwaliteit (o.a. documentatie, testen, codeer stijl) dan krijg je “digitale blaren” die moet je uitprikken en behandelen want als je dat niet doet, krijg je alleen maar meer last en kan het zelfs tot uitval leiden.
laatste gedachten
Software ontwikkeling beschouwen als een marathon leidt tot een mate van respect tonen voor de uitdaging in inspanning en tijd die er voor je ligt. Het lopen van een marathon kan daarom voor veel IT engineers een hele interessante uitdaging zijn die ze niet alleen helpt op het vlak van gezondheid maar ook diepere inzichten kan geven over zichzelf en over software ontwikkeling.
De succesbeleving is de kers op de appelmoes. Op naar langlevende ultra-succesvolle legacy software!
Persoonlijk record tijdens de boerenkool loop 2024
