‘Softwarebouwers mogen zich geen ingenieurs noemen’

Software-ontwikkeling is vandaag nog steeds een behoorlijk amateuristische bedoeling. Te veel lijken ontwikkelaars hun best te doen zonder garantie op een feilloos product, vindt Rudolf de Schipper van Unisys. “Een burgerlijk ingenieur zou het eens moeten proberen: een brug opleveren waarvoor hij ‘zo veel mogelijk zijn best heeft gedaan’.”

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. Met een duur woord wordt softwareontwikkeling ook wel eens software engineering genoemd. Dat is volgens mij een onjuiste voorstelling van zaken. Engineering gaat over het bouwen van dingen, gebruik makend van bekende en bewezen technieken, en met betrouwbaarheid hoog in het vaandel. Als ‘echte’ ingenieurs hun bruggen zouden bouwen zoals we nog steeds software bouwen, zouden maar weinig wagens aan de overkant geraken.

Softwareontwikkeling lijkt in vele opzichten nog geen volwassen stiel. Natuurlijk zijn er fantastische talen waarmee even fantastische toepassingen zijn geschreven. Maar als je het amateurisme bekijkt waarmee sommige ontwikkeltrajecten verlopen, moet je toch je bedenkingen hebben. Sinds de introductie van ‘object-oriented programming’ in de jaren ’80 is er bovendien nog maar weinig fundamenteels veranderd.

Agile development

Een sprekend voorbeeld vind ik agile development: op zich al een enorme verbetering en een eerste stap op weg naar professionelere ontwikkeltrajecten. Als je dan het hardnekkige gerucht blijft opvangen dat het Agile Manifesto (waarin alle principes voor agile development staan opgelijst) werd geschreven na consumptie van een forse dosis bier en whisky, moet je toch wel even de wenkbrauwen fronsen. Uiteindelijk zijn de onderliggende uitgangspunten van agile development eigenlijk niet meer dan enerzijds het aanvaarden dat we slechts een zeer beperkte hoeveelheid complexiteit in één keer kunnen ontwikkelen, en anderzijds de realisatie dat de ontwikkeling van nieuwe vragen en eisen altijd sneller gaat dan de ontwikkeling van de software zelf.

Het ‘antwoord’ van Agile is hier toch wat teleurstellend: de snelheid van een agile project wordt gedefinieerd door hoe snel het team een minimale oplossing kan leveren, en het antwoord op verandering is slechts “wees erop voorbereid”. Dat geeft toch het gevoel dat het hele concept van software engineering is gereduceerd naar “we doen ons best”. Om nog maar eens terug te komen op onze bruggenbouwers: zou jij een brug oversteken als er een bordje bij stond met “we hebben ons best gedaan”…?

Kans op beterschap

Het gebrek aan maturiteit in de development sector vertaalt zich in verschillende vormen van uitwassen. Enerzijds voelen bedrijven zich overgeleverd aan de goodwill van developers en ‘software engineers’ omdat ze totaal geen inzicht hebben in het ontwikkelproces en wat al dan niet mogelijk is. Anderzijds worden ontwikkelaars en software- en dienstenleveranciers opgejaagd door bedrijven die het over een andere boeg gooien en gewoon de boel uitbesteden aan de laagste bieder. Of zetten we massaal in op COTS (Common of the Shelf, standaard software) producten, wat weer een pak eigenaardigheden en problemen met zich meebrengt. Zoals het feit dat het niet precies doet wat je wil: daar is het tenslotte standaard voor. En dan gaat menige organisatie zich te buiten aan “customisation“, wat vaak een situatie oplevert die verrassend gelijkaardig is met een software development traject: te laat, te duur en het doet nog niet wat je wilde.

Het kan nochtans anders. De huidige generatie van programmeertalen is misschien niet spectaculair verbeterd maar je kan er wel veel efficiënter mee coderen. De laatste hype hier heet “low code”, het belooft meer functionaliteit met minder lijnen code. En minder lijnen code betekent minder kans op fouten, en ook sneller klaar, nietwaar? Tja, in theorie zeker wel. Als je echter onder de motorkap kijkt, zie je toch veel oude wijn in nieuwe zakken: voor gedefinieerde libraries en API, wederopstanding van “drag & drop” visueel development en vooral veel beloftes.

Daarnaast is het ook niet zeker of iedereen hier oren naar heeft. Zolang lines of code of uren gewerkt nog een gebruikte maatstaaf is voor productiviteit van een developer, is er weinig motivatie om hier structureel iets aan te veranderen.

Is het dus allemaal slecht? Zeker niet, er is wel degelijk vooruitgang. Voornamelijk in het begrip wat er komt kijken bij het bouwen van een IT-applicatie: hoe zet ik mijn infrastructuur op, hoe verzorg ik de deployment, wat doe ik met security en networking. Al deze aspecten ondergaan fundamentele veranderingen en worden meer en meer “software driven” – mét gebruik van “low code” technieken nog wel.

Nochtans moet er meer gebeuren. Vandaag zien we nog steeds dertig procent van alle softwareprojecten falen (volgens het CHAOS report van Standish Group). Dat accepteren we in geen enkele andere sector, en we zouden het ook niet mogen tolereren in software development.

Radicaal kiezen voor nieuwe technologie en werkwijzen zal op korte termijn misschien leiden tot een tijdelijke crisis, maar als we op lange termijn aan een fors tempo willen blijven groeien, zal er toch iets moeten veranderen. De echte ingenieur die erin slaagt een brug te bouwen tussen het amateuristische verleden en een professionele toekomst, verdient een Nobelprijs, wat mij betreft.