‘Code schrijven is niet hetzelfde als bruggen bouwen’

Rudolf de Schipper klaagde er vorige week over dat softwareontwikkelaars te vaak werk afleveren zonder garantie op een feilloos product. Hij noemde ze de naam ‘ingenieurs’ niet waardig. Softwareontwikkelaar (en ingenieur) Kris Peeters dient hem van antwoord.

Op 20 juli schreef Rudolf de Schipper, Senior Project Manager bij Unisys: “Softwareontwikkeling kampt al sinds mensenheugenis met dezelfde symptomen: lange en complexe ontwikkeltrajecten en dito code. Daardoor vertoont het eindresultaat vaak nog heel wat bugs en is het altijd duurder dan zou moeten”. Hij noemt huidige softwareontwikkelaars ‘amateuristisch’ en de naam ‘ingenieur’ niet waardig.

Ik kan me perfect voorstellen waar die opgeklopte frustratie vandaan komt. Ze lijkt te komen van iemand die jarenlang grote software-projecten geleid heeft. Die hebben altijd hetzelfde patroon: er wordt een megadeal getekend van enkele miljoenen euro’s om een oud systeem compleet te vervangen. Aangezien dat een project van jaren is, worden er in een eerste fase een tiental business analisten ingeschakeld om exact te definiëren wat de klant nodig heeft. Als zij hun werk gedaan hebben, is het de taak van de technische analisten en de architecten van deze wereld om heel precies de business requirements om te zetten in technische noden en een globale IT-architectuur die die noden kan inlossen. Want een professional denkt wel na over het grote plaatje alvorens hij begint. In een volgende fase worden minstens vier blikken van tien software-ontwikkelaars open getrokken die alle technische noden kunnen implementeren volgens de IT architectuur aangegeven door de architecten. We zijn uiteraard mee met onze tijd, dus we doen dit “agile”. We zetten hier drie project managers op om alle technische noden in een backlog te steken. En het is aan de vier software teams om de backlog, goed voor twintig manjaar werk, in korte sprints van twee weken op te leveren. We halen er voor de volledigheid nog een certified scrum master en een agile coach bij. In een volgende fase worden twintig testers ingezet om alles manueel te testen. Liefst zitten deze testers op een ander continent, om kosten te besparen. Want wij zijn ervaren managers, dus kostenefficiënt. Ten slotte wordt alles netjes gedocumenteerd in een groot Word-document en naar de Operations afdeling gestuurd, waar het gigantische IT project na drie jaar werk eindelijk in productie kan worden gezet zodat het de beloofde business value van drie jaar geleden kan opleveren. Mission accomplished. Miljoenen in de pocket. Op naar het volgende project.

Klein probleempje: dit zijn allemaal leugens die de grote consultancies verkondigen aan de onwetende klanten. Deze projecten worden inderdaad, zoals De Schipper zegt, altijd te laat, te duur en met veel bugs opgeleverd. Dat is al decennia lang geweten. En dus kruipt De Schipper in de pen en verwijt hij de domme software developers dat ze geen vakmanschap afleveren.

Wel Rudolf, alles wat hierboven beschreven staat, is een perfect voorbeeld van management-falen, niet van engineer-falen. Ingenieurs weten al sinds het agile manifesto, waar jij zo mee spot, dat er een betere manier van werken bestaat. En sinds de DevOps-beweging, weten we ook al dat er manieren zijn om én snel én high-quality code op te leveren. Het één versterkt het ander. Het is al meermaals bewezen dat we het product sneller kunnen opleveren als we er continu en gedisciplineerd kwaliteit kunnen inbouwen. Dan heb ik het niet over scrum, maar over Test Driven Development, Continuous Integration, Continuous Deployment, Infrastructure as Code, cloud-native architectures, kubernetes clusters, micro-services,… En we tekenen geen miljoenen contracten die fixed price, fixed scope en fixed deadline zijn. Integendeel, we maken een budget vrij, en we definiëren een objective. Dan is het aan het development team, om samen met de business, in korte iteraties, dichter bij dat doel te geraken. Dat heet dan weer lean manangement.

Agile, DevOps, lean, …: in jouw wereld allemaal woorden verzonnen door luie ontwikkelaars en hippies die zich niet aan een project-schema kunnen houden. In de echte wereld daarentegen boeken ze ontzettend knappe resultaten. Kijk bijvoorbeeld naar het engineering masterpiece van de Netflix-architectuur. Netflix runt continu een Chaos Monkey in haar eigen productie-systemen. Deze Chaos Monkey verbreekt willekeurig verbindingen, zet willekeurig servers af, en verstoort communicatielijnen. Hierdoor blijft Netflix altijd stabiel draaien, ook als er echt iets mis gaat. We hoeven echter niet alleen over de landsgrenzen te kijken. Hier in België zijn zowel start-ups als grote ondernemingen knap aan het innoveren.

Nee, Object Oriented is niet de laatste grote verandering in IT. Functionele talen winnen terrein. Kleinere onafhankelijke diensten worden belangrijk. NoSQL-databases nemen markt in. Real-time streaming analytics frameworks worden matuur, … zelfs banken zijn agile, DevOps en Lean beginnen omarmen. Deze bedrijven bouwen strakke en gedisciplineerde cross-functional teams en mikken op minstens tien code deployments per dag.

Want dat is nog iets dat nog niet geklikt heeft. Code schrijven is niet hetzelfde als bruggen bouwen. Code is de beste abstractie in de digitale wereld. De code is de blueprint, die beschrijft hoe een brug moet gebouwd worden. De code deployen en runnen in productie wil zeggen in die bepaalde omgeving een nieuwe brug zetten. En zo bouwen we honderden tot duizenden bruggen per dag, op servers die op elk moment kunnen crashen, met netwerkverbindingen die op elk moment kunnen uitvallen. En toch blijven de bruggen automatisch gebouwd worden, zodat de Belg mobiel kan bankieren via zijn smartphone, zijn digitale tv kan bedienen, zijn favoriete nieuwssite kan bezoeken, zijn e-commerce-bestellingen kan plaatsen, en nog veel meer.

En dát, beste Rudolf, is een knap staaltje van top-software-engineering, hier in België gemaakt. Dus de volgende keer dat jullie nog eens beginnen aan een groot miljoenenproject, één tip: zet eens een stap opzij en laat de gepassioneerde software-engineers hun werk doen. Tenminste, als die bij jullie nog niet allemaal zijn gaan lopen.