Small steps by mankind

Rond de kerst mocht ik weer genieten van de The Royal Institution of Great Britain Christmas Lectures. Dit keer niet de meest recente versie maar de naar grote waarschijnlijkheid zeker niet minder interessante ‘Growing Up in the Universe’ lectures door Richard Dawkins, zoals uitgezonden door de BBC in 1991. Voor dit verhaal verder niet zo bijster relevant, behalve dan dat verschillende aspecten van evolutie worden behandeld. Daarnaast bevatte de aftiteling van de lectures een verwijzing naar wat eigenlijk wel een kleine revolutie mag worden genoemd. Of beter; juist de afwezigheid ervan; in 1991, een goede 15 jaar geleden, had de BBC nog geen website.

Als het gaat om evolutie of revolutie vinden veranderingen in ons vakgebied meestal op een evolutionele manier plaats. Hoewel vaak met de mond beleden is er niet vaak sprake van een echte revolutie.

Marketing driven development

Een duidelijke evolutie, of trend in de ontwikkelingen is die van de RAD tools. Elke nieuwe variant probeert de ontwikkelaar tools in handen te geven om de Rapid van RAD beter gestand te doen. Dit zonder de kwaliteit van het eind product negatief te beinvloeden natuurlijk.

Er is in de manier van ontwikkelen in de loop der jaren een duidelijke verandering opgetreden; ontwikkeling is nu vaker marketing driven. Een gevolg hiervan is dat bij ontwikkeltrajecten nu vaak een soort omgekeerde waterfall methode moet worden gebruikt. Allereest wordt de deadline van het project vastgesteld, vervolgens het budget bepaald en uiteindelijk worden de specificaties vastgesteld. Vanwege de deadline is het project vaak al (ver) onderweg voordat de specificaties geheel duidelijk worden, als ze dat al ooit worden.

A new way of development

Vanwege deze ‘nieuwe’ manier van werken wordt, naast de vraag naar ‘betere’ ontwikkel tools, ook de vraag naar ‘nieuwe’ ontwikkel methodes steeds groter. Desondanks hebben alternatieven zoals de agile programming ontwikkelmethode(s) nog geen vaste voet aan de grond gekregen. Hoewel ze al langere tijd bestaan en beter aansluiten bij marketing driven development, is de waterfall methode, ondanks zijn beperkingen, nog steeds de meest gebruikte.

Waarschijnlijk, in een poging om agile programming modellen beter geaccepteerd te krijgen, worden in de ontwikkeling daarvan ook nog steeds kleine stapjes gemaakt. Scrum is een van de laatste, wat meer een projectmanagement methode is, maar welke soms als agile programming sausje over een verder toch sterk waterfall geörienteerd project gegoten wordt. De grote stap naar ‘full-on’ agile programming is echter nog niet gemaakt.

Agile software development can work

Intussen al heel wat jaartjes geleden heeft een aantal collega’s een proef gedaan met de meest bekende agile programming variant; eXtreme Programming (XP). Een van de conclusies die we konden trekken was dat XP goed kan werken als er een direct contact met ‘de klant’ is. ‘De klant’ zijn daarbij alle stakeholders van het te ontwikkelen systeem. En daar wringt vaak de schoen. Weinig klanten zijn bereid of in staat om deze ‘all access’ op een effectieve manier te organiseren. Hierbij is namelijk vaak persoonlijk contact een must. Maar alle stakeholders altijd op een korte afstand beschikbaar houden, is vaak niet mogelijk of het is domweg te duur. Zonder deze korte lijnen echter vervalt XP al snel in een verkorte en itererende versie van de waterfall methode.

De waterfall methode biedt in dergelijke gevallen een veiligere manier; vooraf wordt tot op de komma nauwkeurig vastgelegd wat er ontwikkeld zal worden, of in ieder geval een poging daartoe gedaan. Vervolgens begint, naast de daadwerkelijke ontwikkeling, het projectmanagement-spel waarbij de manager de scope, het budget en de deadline probeert te handhaven terwijl de klant de veranderende specificaties gerealiseerd probeert te krijgen.

Een van de laatste projecten waar ik aan gewerkt heb bleek achteraf gezien sterke trekken van XP te vertonen. Twee ontwikkelaars die nauw (bijna als pair programmers) samenwerkten, een build systeem dat voor de regressie test op unit niveau zorgde, een tester die de integratie testen uitvoerde en een projectmanager die alle stakeholders binnen handbereik had om het resultaat te evalueren en daar waar nodig commentaar te geven en de specificaties aan te passen of te verduidelijken. Omdat de software ook nog eens op een bestaand pattern gebaseerd kon worden, was het project in 8 werkdagen gerealiseerd.

Ter vergelijk; andere projecten van deze orde hadden een doorlooptijd van maanden waarbij de fase waarin de specificaties worden bepaald en vastgelegd alleen al een paar weken in beslag nam en een is zelfs nooit de requirements fase uit gekomen.

In de juiste omgeving kan agile software development dus goed werken en is dan in de huidige markt vaak beter op zijn plaats dan de waterfall methode. Desondanks heeft de evolutie of zelfs revolutie naar het gebruik van agile programming nog niet plaats gevonden. En het lijkt er ook niet op dat dat binnenkort zal gebeuren.

The open source (r)evolution

Zoals duidelijk moge zijn, wordt in het voorgaande voornamelijk het ontwikkelen van software voor ‘derden’, het zogenaamde maatwerk, bedoeld. Nu veelal uitgevoerd als fixed-price or uurtje-factuurtje project.

In de ontwikkeling van ‘shrink-wrapped’ applicaties heeft er de laatste jaren wel een evolutie plaats gevonden; open source en het bijbehorende business model. Hoewel niet direct noodzakelijk, wordt de software die als open source is ontwikkeld vaak gratis aangeboden. Als er al iemand geld mee wil verdienen dan wordt dat gerealiseerd door extra services te bieden. Hoewel het concept waarbij producten tegen lage prijs worden verkocht en vervolgens op services wordt verdient niet echt nieuw is, heeft er wel duidelijk een evolutie plaatsgevonden.

Added value

Een manier van zakendoen die opgeld doet zou je een variatie op het open source model kunnen noemen. De services worden hierbij gratis verleend, betaald wordt alleen de toegevoegde waarde. En dan niet de toegevoegde waarde zoals gebruikt in BTW, maar de meerwaarde voor de klant. Het aardige is dat de klant mag bepalen of en zo ja wat die toegevoegde waarde is. Dat lijkt een uitnodiging voor het niet betalen voor geleverde diensten, maar als die diensten een duidelijke meerwaarde hebben gehad dan zal het niet zoveel moeite kosten om de klant te overreden een deel ervan als beloning ter beschikking te stellen.

Aardig aan deze manier van zakendoen is dat het twee belangrijke aspecten vooraf al als aanwezig veronderstelt. Namelijk vertrouwen in elkaar en geloof in eigen kwaliteit. De vertrouwensrelatie wordt omgedraaid; in plaats dat de klant er maar op moet vertrouwen dat een goede dienst en/of product zal worden geleverd, moet de leverancier er op kunnen vertrouwen dat de geleverde meerwaarde duidelijk zal zijn en de beloning daarvoor hoger dan de kostprijs zal liggen. Hiervoor moet de leverancier dus vertrouwen en geloof in de eigen kwaliteit hebben, wat het makkelijk maakt voor de klant om dit geloof te delen. Een dergelijk sterke vertrouwensrelatie biedt ook de mogelijkheid tot openheid die de relatie eigenlijk alleen maar ten goede kan komen.

Viva la Revolución

Daarmee kan dan eindelijk ook het rigide waterfall model de deur uit; er hoeft niet meer op de komma nauwkeurig te worden beschreven wie wat wanneer doet en vervolgens veel tijd besteed aan het vasthouden van die afspraken. Er kan daarentegen een meer vloeiend model worden gebruikt zoals bijvoorbeeld eXtreme Programming. Niet voor niets passen de core values daarvan, zoals oa ‘Moed’ en ‘Respect’ prima in het toegevoegde waarde business model.

Ik denk dat er nog wel wat tijd zal verstrijken voordat dit nieuwe model gemeengoed is. De kans bestaat zelfs dat het een van de vele hypes wordt die na korte tijd weer een stille dood sterven. Maar als concept heeft het zijn charme en er is eigenlijk geen reden om het, al dan niet op kleine schaal, toe te passen.

Het is langzamerhand weer tijd voor een kleine revolutie.

——————————————————————
Meer weten over Java-specialist Finalist IT Group?