Software-bouwers zijn de menswetenschappers onder de ingenieurs
(of zouden dat moeten zijn)
Het artikel bevat boeiende stellingen en terechte kritiek op de "state of the union" van software engineering. Het vertrekt helaas van een volledig fout uitgangspunt: een software-project vergelijken met het bouwen van een brug. Daardoor mist het de kans op nog meer nuttige conclusies.Dat foute uitgangspunt toont de kern van de zaak: een aangeleerd verkeerd beeld van software bouwen. De idee dat dit zou *moeten* engineering zijn; de miskenning dat het ook een menswetenschap is. De gevolgen van dat foute beeld zijn erger dan een minder nuttig artikel in je vakblad. Erger dan de opgelopen frustratie van de gefaalde projecten. Dat foute beeld zorgt dat we niet aan de spiraal ontsnappen. Omdat we te weinig de juiste mix van mensen in de juiste opleidingen en de juiste jobs krijgen.
Software krijgt de aandacht die ze niet verdient.
Het artikel stelt dat software-projecten vaak mislukken. Maar was de definitie van succes vooraf vastgelegd? Als justitie digitaliseert, maar de magistraten weigeren hun gegevens in het systeem te stoppen (omdat het “te moeilijk” is), dan wordt de mislukking breed uitgesmeerd in de pers. Als ondanks de peperdure archiefkasten, de magistraten toch hun dossiers laten rondslingeren op bureaus of in de gang (omdat de kasten in de kelder staan), dan is dat infrastructuurproject evengoed mislukt. Dit tweede scenario krijgt veel minder aandacht. Vreemd?Om in de sfeer van het gerecht te blijven: het Antwerpse justitiepaleis is een mooi voorbeeld van mislukte 'architectural engineering'. Het is een prachtig gebouw, dat de skyline van de stad vanuit het zuiden kenmerkt, maar na slechts vijf jaar zijn de prachtige houten vloeren helemaal stukgelopen en bevlekt: te veel voetverkeer en gemorste koffie. Bovendien plakken de muren en deuren vol met snel-snel geprinte papiertjes om bezoekers de juiste richting te wijzen. De structuur is te complex en de signalisatie ondermaats. Falen blijkt ook buiten software bekend. Het institutionele steiger-harnas van het Brusselse zustergebouw moeten we niet eens aanhalen.
Software is veel eenvoudiger
Toch moet de software-branche niet meteen de borst nat maken. "Pure Logica", de grondstof van de software bouwer, laat zich makkelijker kneden dan zijn fysische tegenhangers: gewichtig beton, draaiende onderdelen in motoren, hete plasma-wolken en reactorvaten vol borrelende chemicaliën.Een for-next-loop vlotjes uit de mouw schudden gaat zonder rekening te houden met de eigenfrequentie van de CPU. Geen enkel gevaar dat die plots door resonantie door het scherm wordt gekatapulteerd. De waarde van een variabele wordt niet angstvallig in de gaten gehouden uit angst dat die het smeltpunt van de silicone drager overschrijdt. Werken als software-bouwer gebeurt niet op een werf met een helm, maar in een vrije speeltuin zonder gevaar.
Oké, er zijn wat paradoxen, nog immer etterend uit de tijd van Russel, Gödel en Turing; de dreiging van depressies veroorzaakt door de existentiële stress rond de beperkingen van formele logica. Maar het blijft een verloren zaak voor de uitgekookte software-vakbond die op basis daarvan de toevoeging op de lijst van "zware beroepen" bepleit.
Software is in grote mate arbitrair
En toch. "Het gemak van die pure logica" maakt ons meteen blind voor de beperkingen ervan. Het creëert de sfeer van ongebreidelde fantasie, opgeblazen verwachtingen, onuitputbaar optimisme en hardnekkig geloof in de mogelijkheden. Minstens zo vaak bij de vraagstellers als bij de bouwers zelf.Die ongebondenheid slaat alle fundamenten weg die aan de "echte wereld" zijn zalige zekerheid en stabiliteit verleent. Hier geen algemeen geldende wetten, geen vastgelegde richting of zekere grootte van de zwaartekracht, geen universele constante van Planck, geen betrouwbaar dauwpunt van de waterdamp.
In ruil ontwaakt de software-bouwer elke werkdag in een wereld die bol staat van van-de-pot-gerukte arbitraire feiten en regels. Slechts begrensd door de inspiratie en overredingskracht van de klant of verkoper. Van de techniek zelf komt ook weinig steun: bestaande deeloplossingen hergebruiken (bibliotheken, modules en componenten) betekent navigeren door een veld dat door die andere ontwikkelaar achteloos is bezaaid met anti-persoonsmijnen: te volgen (onnavolgbare) "logische" stappen en in te stellen obscure configuratie; alles met niet te bedenken arbitraire namen en locaties die verplicht subtiel veranderen van versie naar versie.
In beide richtingen is er bitter weinig basis voor betrouwbare vergelijkingen omtrent de ‘engineering’.
Vooral de Software-economie is jong
Het is een verrekt jong idee, dat idee om “Algoritmische gegevensverwerking formeel zo te beschrijven dat ze machinaal kan uitgevoerd worden”. Daar moeten we niet op afdingen. Napoleon had het twintig decennia geleden niet kunnen bedenken, terzelfdertijd had hij geen moeite zijn troepen in Egypte inspirerend toe te spreken in de driehoekige schaduwen van "reeds veertig eeuwen bouwgeschiedenis". Toen al. Vermoedelijk is de innovatie in die klassieke tak van het ingenieurswezen nog immer aan de gang. Ondertussen is wel hun prijsstelling gestabiliseerd; de marges en verwachtingen stilzwijgend afgesproken. We moeten daar niet flauw over doen: het betekent dat we hebben leren leven met de bouwkundig ingenieur die sans gêne bovenop zijn sterkteberekening een forse veiligheids-multiplicator mag hanteren; dat we het gewoon zijn dat de toegelaten foutenmarges worden opgevuld in de voeg of verstopt achter de sierlijst.Dus laat ons elkaar geen Liesbeth noemen. De frustratie gaat over centen. Wat mogen we per geïnvesteerde euro verwachten? Of er bij de andere ingenieurs vaker of niet tegenvallers zijn op dat punt doet er dan niet toe: In de eigen winkel moeten we deemoedig onderschrijven dat er nog immer ruimte is voor verbetering.
Die haven met verhoopt "rustiger wateren" is mogelijks nog veraf. Beton wordt niet elke achttien maand twee keer zo sterk en twee keer zo licht. Moore inroepen als makkelijke zondebok is niet de bedoeling. Maar de meest nabije "stabiele economische wet" in de sector heeft een ruikende adem: de ingebakken verwachting van exponentiële groei. Vanzelfsprekend haast: die dromen van onbegrensde mogelijkheden. Ook in de markt. Wereldwijd. Je kunt elke Aardling een herkenbaar lijstje van IT topbedrijven laten ophoesten, maar de laatste IPO van bouwbedrijf X zal je enkel een glazige blik opleveren. Het vale canvas van de software-projecten-centen-frustratie verbergt een goudmijntje.
Appels met appels
Laat ons toch proberen de vergelijking goed te krijgen. Een goede, stabiele brug neerpoten is een technisch hoogstandje dat sterk lijkt op het gepast en correct toepassen van een gekend OOP patroon, of het foutloos implementeren van een bewezen algoritme. Voorbijgaand aan de variërende complexiteit: Van bubble sort tot Paxos of Merkle tree, als de formele beschrijving maar goed zit, is dit net zo goed te behappen en binnen afgesproken verwachtingen uitvoerbaar. Effe een bruggetje leggen.Nemen we echter een matig complex software-project, dan vergelijkt zich dat in de sector bruggen-en-wegen al snel met "Het ontwarren van de mobiliteitsknoop rond Antwerpen": Wordt het nu een brug of een tunnel? Moet er strategisch in de toekomst meer of minder, zwaarder of lichter verkeer, dichterbij of verderaf van de stad? Hebben we door achteloosheid in de uitnodiging voor het overleg een aantal belangrijke stakeholders over het hoofd gezien? Toch niet de bewoners of onze kiezers?
Verrassend. Zonder zelfs bij benadering het budget van dat gemiddelde bruggetje, met slechts een fractie van het aantal betrokken uitvoerende voltijdsequivalenten; we kijken meteen naar een project waar naast het strikt "technische", opvallend veel ruimte blijft voor de "sociale" variant van engineering.
Niet in het sausje overigens, maar in het vlees én het bot. Want het gaat niet over die jeweetwel "soft skills" (De gebruikers van die term moeten dringend voor ‘skill-shaming’ veroordeeld kunnen worden) Dus niet over taal- en communicatie vaardigheden, niet over de te hanteren diplomatische stijl noch over het knuffelgehalte van de 'teamplayer'. Die saus is uiteraard belangrijk, maar ze is slechts van tweede of derde orde. Ze is dan ook maar nuttig zolang ze ten dienste blijft van wat er echt aan de hand is: een zoektocht naar duidelijkheid en betekenis. De echte kost van software bouwen zit in het ontdekken van wat precies moet gebouwd worden. Dat aspect vergt een talent om de vertaalslag te maken van de informele wereld van idee, vraag en inspiratie naar de formele oplossing: concreet en uitvoerbaar. Daarin zitten elementen van de (met gepast respect) "harde" menswetenschappen: taalkunde, communicatie, bibliotheekwetenschappen, psychologie, zelfs filosofie. Dit gaat over het begrip van mens, brein en taal. Zolang we dat niet aanduiden in het takenpakket krijgt het ook geen aandacht in de opleiding.
Wat weten we al met enige betrouwbaarheid? Hoe werkt ons brein? Wat zijn de correcte classificaties die we moeten aanbrengen, en wat zijn de intrinsieke beperkingen die we onszelf ermee opleggen. Wat betekent elke term echt? Wat betekenen ze vooral niet? Hoe beheren we de semantiek? Hoe zal dit systeem gelezen en gebruikt worden? Hoe stuurt (taal)gebruik effectieve betekenis (Jaja, Ludwig, jaja!).
Taal en letteren
De auteur van het originele artikel heeft zonder meer recht op zijn frustratie. Object Oriented Programming (OOP) heeft ons niet in het Walhalla gebracht. Het is nochtans een vruchtbare injectie van inzichten uit de bedrijfskunde: Formuleer de organisatie van de oplossing in termen van samenwerkende, vervangbare onderdelen met betrouwbare onderlinge contracten; verlaat daarbij de door bandwerk geïnspireerde visie van de procedurele oplossing als (te) strikt stappenplan.Ook op zijn plaats: de kritische noot bij de resultaten van de methodologie. De binnengebrachte inzichten uit boekhouding en time-management zijn zeker een meerwaarde. Meer waard dan het gekibbel over het gidsende beeld erbij. Wisselend met de mode gaan we voor de vurige responsieve lenigheid (agile) of voor de wetmatige zekerheid van vallend water. De poëzie van die achterliggende beelden is zeker nuttig voor de sturing van je team, maar minder belangrijk dan de gepaste aandacht voor tijd-, taak- en feature-beheer an sich.
Er is nog meer evolutie in de taalstructuren. Aspect Oriented Programming (AOP) is een aanvulling op Object Oriented Programming die te vergelijken is met het toevoegen van adjectieven aan een concepten-taal die daarvóór enkel bestond uit substantieven en werkwoorden. Of neem Language Oriented Programming (LOP). "Bouw een parser die de formele specificaties kan begrijpen, en je probleem is opgelost. Als je daarna de use cases in die taal kunt uitdrukken zijn meteen ook de unit-tests klaar!". Dit soort externe invloeden dragen de erkenning dat software draait rond een dynamisch en complex probleem van taal en begrip. Niet 'slechts' een hydrostatisch dammetje of een listig truukje met voorgespannen beton. De overtreffende trap stormt vandaag de branche binnen: Artificiële Intelligentie. Vergeet de zoektocht naar de oplossing zelf, maar simuleer de werking van een (talig) brein waarvan we niet hoeven te begrijpen hoe het werkt. als het maar tot betrouwbare oplossingen komt.
Mag Luc Steels, van opleiding linguïst én toonaangevend Belgische AI onderzoeker aan de VUB, zich wel ingenieur noemen? Vinden we dát belangrijk?
De oplossing is niet (altijd) méér engineering
De onderstroom van het artikel is dat langs de as van falen tot succes gemeten wordt in eenheden "ingenieur". Is dat niet meer dan een beetje zelf-verheerlijkend elitair? Ontluisterend: Minus de exotiek van de business talk wordt de historisch meest correcte vertaling eenvoudig "machinist". Akke-akke-tuut-tuut, voetjes op de grond! Blijven roeptoeteren om "meer ingenieurs" moet dringend vervangen door zoeken naar het opleiden van betere ingenieurs. Ingrijpender dan de "extraverte ingenieur" uit de klassieke grap: hij die naar joúw schoenen kijkt terwijl hij tegen je spreekt; maar iemand die voldoende inzichten meekreeg over haar menselijke soort zelf.De tijd van de witte raven en de homo universalis ligt ver achter ons. Doorgedreven specialisatie heeft die vervangen door interdisciplinaire netwerken van experts. De Da Vinci van onze tijd die de code kraakt zit verborgen in de interactie van mensen. “Mens” omvat gewillig wel-en-niet-ingenieurs, op voorwaarde dat ze elkaar kunnen en willen begrijpen en erkennen dat ze uit hun wederzijdse dialoog iets kunnen leren.
Er mogen nog vele correcties aan het softwarebedrijf worden aangebracht. De kans wordt alsmaar kleiner dat die komen van één, aanwijsbaar individu die daarvoor dan een Nobelprijs krijgt. Bijna zeker is dat de drijfveer van de aanbrengers niet zal zijn: "zichzelf ingenieur te mogen noemen".
🙖🙖🙖
Deze uitgeschreven reactie en opinie kwam mee tot stand dankzij de inzichten, wenken, online interacties, existentiële twijfel en de krullende tenen van daarom niet volmondig akkoord gaande collega ingenieurs en software-bouwers: Koen Pellegrims en Erik Mannens. Waarvoor dank.
