Programmeren wordt ook wel het ambacht van de 21ste eeuw genoemd. Het vereist namelijk veel tijd, oefening en talent van de programmeur om een softwarematige oplossing te realiseren door middel van een numeriek algoritme. Helaas introduceert dit ambacht ook veel menselijke fouten, wat de vraag oproept: is softwareontwikkeling wel zo hightech als velen denken?
Het vak van programmeur bestaat pas zo’n dertig jaar en is daarom nog continu in ontwikkeling. Een groep programmeurs ging de afgelopen decennia op zoek naar een gemene deler in het vak. Hieruit kwamen het Manifesto for Agile Software Development uit 2001 en het Manifesto for Software Craftmanship uit 2009 uit voort. Met dit laatste manifest willen programmeurs de lat voor hun vak hoger leggen. Ze willen bijvoorbeeld dat programmeurs niet alleen op verandering reageren, maar ook echt waarde toevoegen. Dat is op zich een goed initiatief, maar neemt niet weg dat het softwareontwikkelproces de afgelopen dertig jaar nauwelijks is verbeterd. En dat terwijl in diezelfde periode bijna alle industrieën hun processen hebben geautomatiseerd. Denk alleen al aan de automotive-industrie.
Programmeren oude stijl
De behoefte aan software groeit met de dag, maar de grootste bottleneck blijft de ontwikkeling. Dat gebeurt namelijk nog steeds grotendeels handmatig en op ongeveer dezelfde manier als dertig jaar geleden, met alle gevolgen van dien. Een organisatie bedenkt bijvoorbeeld een complex nieuw product en produceert vervolgens een dikke stapel papier waarin het uiterlijk en de functionaliteit van de software wordt beschreven. Deze dikke stapel documentatie wordt daarna overhandigd aan een groep gebruikers die alles moet controleren. Stel je voor dat je de software halverwege of achteraf nog moet aanpassen!
Na de goedkeuring moet een groep programmeurs vervolgens miljoenen regels code schrijven om het nieuwe softwarepakket tot leven te wekken. Hierbij wordt waarschijnlijk een programmeertaal gebruikt die op dat moment modern is, maar door de technologische ontwikkeling al heel snel veroudert.
Software wijzigen
Een ander probleem bij grote, met de hand geprogrammeerde projecten is, dat het doorvoeren van wijzigingen heel complex is. Vergelijk het met het plaatsen van een houtkachel in een bestaande woning. Er is dan een heel ander rookkanaal nodig, waardoor er op meerdere verdiepingen flinke aanpassingen gedaan moeten worden. Programmeurs worden weleens de digitale bouwvakkers van de toekomst genoemd. Het gezegde ‘oefening baart kunst’ past hier goed bij.
De uitkomst is zelden exact te voorspellen en projecten zijn bijna onmogelijk te begroten. Zelfs als Agile- of Scrum-technieken worden gebruikt, is de kans dat een project binnen de tijd, specificaties en budget wordt opgeleverd slechts miniem. Daarom lezen we ook regelmatig in de krant dat er weer een it-project volledig uit de hand is gelopen. Is het niet hoog tijd dat het ambacht programmeren vervangen wordt door efficiëntere, snellere en foutloze manieren van software bouwen?
Programmeren nieuwe stijl
De ontwikkeling van software wordt weleens vergeleken met de automotive-industrie. In zo’n hightechindustrie wordt altijd eerst een digitale bouwtekening van een conceptmodel gemaakt, die vervolgens op allerlei manieren gevisualiseerd en gepresenteerd kan worden. De auto kan in deze virtuele vorm zelfs volledig automatisch getest worden, bijvoorbeeld om te kijken of de auto niet als een harmonica in elkaar wordt geduwd bij een botsing. Zijn alle belanghebbenden eenmaal tevreden over het concept, dan wordt de bouwtekening aan een lange robotstraat gevoed, die er voor zorgt dat de productie zo geautomatiseerd mogelijk kan plaatsvinden.
Gelukkig zijn er ook mogelijkheden om softwareontwikkeling op een vergelijkbare hightech manier te verbeteren, namelijk met een low-code software development platform. Met dit type ontwikkelplatformen wordt een voor iedere organisatie unieke virtuele blauwdruk van de specifieke bedrijfsprocessen gemaakt. Op basis hiervan wordt vervolgens automatisch bedrijfssoftware gerealiseerd, die daarna flexibel en tegen beduidend lagere kosten aangepast kan worden, enkel door de virtuele blauwdruk te wijzigen. Hoeveel dit kan schelen is in dit QSM Rapport terug te vinden. De software wordt in feite gemodelleerd, met zo min mogelijk programmeerwerk. Aanpassingen kunnen doorlopend gedaan worden, zonder trapsgewijze updates of volledig nieuwe implementaties. Door deze aanpak ontstaat er een software-lifecycle die beter past bij de technologische wereld waar we nu in leven. Een waar software zich vormt naar de organisatie en niet andersom.
Vraag me af of de schrijver überhaupt zelf wel ervaring heeft met het onderwerp waar hij over schrijft of zijn ervaringen nog van de vorige eeuw stammen.
In de bouw gaat er ook van alles fout omdat de bouwtekeningen fout zijn of dat iemand met een maandagochtend kater even niet op zit te letten. Dat is in de software ontwikkeling niet veel anders. Maar wat er in die 30 jaar wel is gebeurd dat de ondersteuning van de ontwikkeling ontzettend veel is geautomatiseerd en je als programmeur je met de hoofdzaken bezig kan houden omdat al die bijzaken uit handen genomen kan worden.
Bij het programmeren zelf is een veel breder scala aan API’s beschikbaar en is de ondersteuning van IDE’s ook veel geavanceerder geworden. Dat zal in de toekomst alleen maar toenemen.
Agile is net als democratie. Het minste van alle kwaden. Maar ook daar moet je kundig mee omgaan om jezelf niet in je eigen voet te schieten. Dus het inplannen van technical debt hoort daar bij. Plus dat je na elke spring evaluaties uitvoert om verbeteringen aan te brengen aan het proces om te voorkomen om dezelfde fouten te maken.
Wat het rapport betreft. Jammer dat het achter een email vangnet zit. Geen zin in spam dus dat gaat hem niet worden.
Ten aanzien van het mislukken van (grote) ICT projecten en de inzet van de programmeurs.
Het probleem met deze projecten zijn niet zozeer de programmeurs of de techniek. Voortbordurend op de houtkachel analogie: het probleem bij deze projecten is dat de tegelzetter, elektricien, de makelaar én de buurman ook nog persé wat te zeggen willen hebben over het project. En dat uiteindelijk de postbode het besluit moet nemen.
Het probleem is ook dat men halverwege de bouw opeens besluit om een andere houtkachel te nemen. Of nog erger, over te gaan op een gaskachel of een elektrische. Maar dat mag niet meer geld kosten en de reeds aangelegde rookkanalen moeten maar gebruikt worden.
Ook is het een probleem dat de klant eigenlijk helemaal geen houtkachel nodig heeft, maar een nieuwe keuken. Maar dat niet weet of niet wil aannemen.
Ik zie dat mijn blog veel reacties losmaakt en dat dit onderwerp in elk geval leeft. Belangrijk is dat we twee zaken scheiden: de ambacht van het werk zelf, en de opleveringsmethode. Als we een stoel in één keer uit hout snijden op basis van een ontwerp op papier, dan is iedereen het er over eens dat het ambacht is. Als we ieder onderdeel afzonderlijk uit hout snijden, en direct opleveren zodra dat onderdeeltje klaar is, is het proces nog steeds ambachtswerk. We krijgen alleen kleinere brokjes resultaat sneller opgeleverd, dus feedback komt sneller binnen. Hoewel we daarmee het proces flexibeler maken voor de klant blijft daarmee het werk zelf een ambacht. Het hele idee is dat we het ambacht zelf zo min mogelijk moeten doen.
Anders dan bij een gewone handgemaakte stoel is de vertaalslag van een visuele bouwtekening naar een eindproduct in geval van software te automatiseren. Daarmee haal je de foutgevoeligheid weg die in het ambachtswerk zit en het is veel minder tijdrovend. En dan heb ik het niet over het genereren van code zoals we in de jaren 80-90 veel zagen, maar abstracte standaard GUI’s die realtime een bovenliggend model interpreteren. Fouten in bovenliggende bouwtekening kunnen inderdaad nog steeds gemaakt worden, maar deze fouten zijn voor een groot gedeelte in het voorstadium te detecteren door modelmatige validaties en automatisch tests. Zelfs al zou er iets gemist worden is het eenvoudig op te lossen want de vertaalslag naar software is dus automatisch en realtime. Concreet: passend we in het model een schermstructuur aan, voegen we een veldje toe of veranderen we zelfs een complete module, dan is met die aanpassing aan het model het ook direct foutloos doorgevoerd in het eindproduct. Dit alles met een factor 20 minder code dan bij een ‘normale’ .NET of Java applicatie. Dat is ook waar die genoemde productiviteitswinst vandaan komt. We hebben het hier dus niet over sneller (4GL) programmeren (m.i. een sneller paard), maar over low-code MDD voor centrale systemen zoals ERP. Absoluut geen theoretische idealisering maar iets wat wij dagelijks doen voor veel grote bedrijven.
Bij de complexiteit van een ketelstructuur met B2B koppelingen en verschillende protocollen blijft het nog steeds een kwestie van veel handmatig programmeren en zijn er veel onduidelijkheden die vaak pas bij het testen worden ontdekt. Hoe meer ervaring de programmeur heeft in dergelijke situaties hoe sneller en beter de softwarekwaliteit.
Veel systemen bij financials en verzekeraars hebben te maken met complexe ketens. Die bedrijven kunnen dus relatief weinig voordeel behalen uit low-code MDD omdat de systemen op diverse platformen (Mainframe, Midrange en Wintel). Veel programmeurs zijn vaak beperkt tot één á twee platformen met bijbehorende Database engines. De interfaces moeten dan zodanig gedetailleerd worden beschreven dat de ontwikkelaars vanuit ieder verschillend platform exact weet welke gegevens er uitgewisseld worden en in elke vorm.
Voor nieuw te ontwikkelen Webapplicaties is er wel besparing mogelijk, mits er geen complexe koppelingen moeten worden gerealiseerd. Vaak zie je in die projecten een hybride projectstructuur met Agile/Scrum en Cascade gecombineerd.