Er is door de jaren heen een groot aantal software ontwikkelmethodes bedacht. Waren waterval, RUP en DSDM vroeger populair, tegenwoordig is de it-wereld vooral lyrisch over Agile, Scrum en DevOps. Deze nieuwe vormen van samenwerking hoeven echter helemaal niet automatisch een verbetering van het ontwikkelproces te betekenen. Slechte tooling is evenzo vaak een probleem en die tooling is in veel gevallen nog altijd hetzelfde als tien jaar geleden.
Nog niet zo heel lang geleden liep ik een klant tegen het lijf die exact dit probleem had. Het was in veel opzichten een voorbeeldige it-organisatie. De it-afdeling bestond uit mensen die eerder zelf in de business gewerkt hadden en dus ook precies begrepen wat hun wensen waren. Ze gebruikten Agile als ontwikkelmethode voor software-ontwikkeling. En last but not least; ze hanteerden een build-over-buy-principe wanneer het ging om applicatie-ontwikkeling. Ze konden met it dus ook echt het verschil maken met concurrenten.
Praktijk weerbarstig
Deze organisatie had zich ten doel gesteld om meer met klanten te gaan communiceren en ze wilden dit bereiken door meer it-functionaliteit te gaan bieden, zowel via de website als via de mobiele apps. Er moest daarom meer en sneller ontwikkeld worden in kortere release cycli. Voor een goed geoliede it-afdeling als deze zou je verwachten dat dit geen probleem is, maar de . De tooling voor software-ontwikkeling was namelijk niet toereikend. Het bedrijf maakte van oorsprong vooral Uniface-applicaties in een 4GL-omgeving. Door het almaar toenemende belang van internet was de it-afdeling door de jaren heen overgeschakeld naar Java. De complexiteit van het programmeren in Java was vele malen groter dan in de 4GL-omgeving. De productiviteit en het aantal releasecycles ging daardoor omlaag. Bovendien ging er veel tijd op aan het in de lucht houden van applicaties.
Binnen deze context probeerde de ontwikkelaars de iteraties flink in tijd te bekorten. Het zal niet verrassen dat dit telkens niet tot het gewenste resultaat leidde. Applicaties werden wel sneller opgeleverd, maar in de testfase werden zoveel bugs gevonden dat ze eigenlijk alleen maar meer tijd verloren. En slaagde de applicatie eenmaal in de testfase, dan werden er wel kinderziektes aangetroffen wanneer de applicatie eenmaal live stond. Gevolg voor de programmeurs was dat zij regelmatig in de avonduren moesten doorwerken.
Model gedreven
Het management begreep dat de problemen niet in de samenwerking zaten. Er moest iets gedaan worden aan de tooling. Een nieuw Java-framework zou daarbij niet helpen, dat was in het verleden al eens geprobeerd. Weer een nieuw java-framework zou evenzoveel problemen opleveren bij het onderhouden en ontwikkelen van de applicaties als nu het geval was. De oplossing werd gevonden in een model-gedreven ontwikkelplatform. Dergelijk platformen waren er vroeger ook wel, en waren in het verleden ook wel door deze klant onderzocht. Destijds waren dergelijke platformen nog niet dermate volwassen dat ze kwalitatief goede code leverden en goed konden integreren met externe databases. Een aantal van de huidige high productivity ontwikkelplatformen kunnen dat inmiddels wel.
Deze klant heeft na lang wikken en wegen besloten om zo’n nieuw ontwikkelplatform te adopteren. Na anderhalf jaar, met een beperkt deel van het ontwikkelteam, waren ze erin geslaagd om meer dan zeven van de vijftien applicaties te ontwikkelen en in productie te brengen. Iets dat met hun oude Java-framework onmogelijk zou zijn geweest. Dus: it’er, kijk ook eens naar de tooling wanneer je je applicatie-ontwikkeling wilt versnellen. Daar zijn meer slagen in te winnen dan alleen het invoeren van een nieuwe ontwikkelmethode.
Albert Einstein’s quote '' Still repeating the same things over and over again and expecting different results' vat dit mooi samen.
