Mijn vorige projecten waren allemaal Greenfield projecten, projecten die van scratch begonnen en waar ik een grote vrijheid kreeg om te ontwikkelen. Die vrijheid kon ik als ontwikkelaar benutten om nieuwe technologieën te introduceren, het component design zo ‘mooi’ mogelijk te maken, laatste versies van libraries gebruiken, en zo meer. Je gebruikt ook je ervaring om alles zo perfect mogelijk te maken en je te houden aan coding conventions, best practices, guidelines op te stellen. Dit zijn de soort projecten waar iedereen zich wel kan in vinden, niet?

Het klantenverhaal…

In September vorig jaar kreeg ik het nieuws dat ik kon beginnen bij een grote klant. Het is een mastodont van een overheidsinstelling: veel postjes in te vullen, veel projecten, veel bedrijven die ‘binnen proberen geraken’. Kortom, er zijn veel consultants die lange tijd op verschillende projecten meedraaien.

De applicatie draait op Struts 1.3.9, EJB3′s, een zelfgebouwd persistency-framework, een ononderhouden codebase met duplicatie van code, hacks, ‘everything-on-the-session’, String concatenation van soms +40 lijnen(dat is een widescreen laptopscherm vol met lijnen!), 614 VO’s BO’s BC’s Actions Forms zonder hergebruik, constants her en der, geen documentatie, you name it. De schok was groot.

Challenge Accepted!

Ik geef toe, ik had m’n twijfels toen ik dit project aanvaardde. Mijn grootste twijfel was of ik hier wel iets uit ging leren? Struts1, onderhoud, jsp’s, *geeuw*. Achteraf bekeken heb ik andere dingen bijgeleerd op dit project. Ik besefte dit pas toen ik het artikel ‘The Joys of Maintenance Programming‘ las enkele weken terug.

Je leert debuggen

Iedereen weet ondertussen wel hoe hij debugged. Breakpoints zetten, je kent je component diagram, soms weet je gewoon al waar je moet kijken zonder te debuggen! Ik heb ondervonden dat het veel meer inspanning en doorzettingsvermogen vraagt om andermans code te begrijpen en te lezen. Stap voor stap moet je de oorzaak van het probleem proberen achterhalen. Misschien gebeurt er op andere plaatsen nóg meer? Of wordt het misschien herbruikt? Je kunt dus niet zomaar veronderstellingen maken, maar je moet je volledig ‘inleven’ in de code.

Het lezen en debuggen van vreemde code doet je nadenken over hoe de code (niet) werkt, in plaats van wat je denkt dat het zou moeten doen.

Je leert beter programmeren

Het is duidelijk uit voorgaand punt dat het gemakkelijker is om goede code te debuggen dan slechte code. Goede code kan (hopelijk ) iedereen hier schrijven. Maar wat is slechte code? Wel, dit onderscheid zal je zeker en vast ondervinden op een onderhoudsproject. Je zult de ‘waarom’ achter code moeten achterhalen, wat de bedoeling was van de programmeur. Ervaren programmeurs herkennen onmiddelijk het verschil tussen goede en slechte code, en omgaan met ‘meer code’ (niet enkel die van jou of andere ervaren mensen) zal dit gevoel enkel versterken.

Je ontwikkelt manieren om je weg te vinden in een onbekende codebase, en je zult een neus ontwikkelen voor code waar een reukje aan zit.

Je leert optimaliseren

De originele programmeurs hebben hun premature optimizations al kunnen doen (niet door laten verleiden! Premature optimization is the root of all evil). Jij kunt nu de échte efficiëntieproblemen en bottlenecks vaststellen. De originele programmeurs staken veel tijd en energie in wat zij als mogelijk performantieprobleem zagen. Problemen die misschien nooit zouden voorgevallen zijn, of die geen grote impact zouden gehad hebben.

Werkende systemen hebben reële performantieproblemen. Het is een heel nobele vaardigheid die de gebruikers zeker positief zullen onthalen om deze problemen te identificeren en er oplossingen voor te formuleren. Het zoeken en oplossen van deze problemen kan zelf leuk worden!

Klanten merken altijd wanneer je hun applicatie sneller maakt, en appreciëren het enorm wanneer je er aan denkt om ze efficiënter te maken.

Je leert met gebruikers omgaan

Bij greenfield projecten werk je vooral binnen het team. De analye is klaar, de business is gecontacteerd, de requirements liggen vast (althans, dat hoop je altijd). Nieuwe applicaties hebben geen echte gebruikers, je krijgt use cases en stakeholders. Bij onderhoudsopdrachten werk je met de eindgebruikers, vooral diegene die de applicatie dagelijks gebruiken en die zich ergeren aan de bugs of aan functionaliteit die niet of slecht werkt.

Communiceren met eindgebruikers die uit een niet-IT-achtergrond komen doet je uit je IT-schelp kruipen. Hierdoor voel je je meer betrokken tot je werk.

This post was mentioned on RealDolmen NoNonsense Blog, and DZone