Managed hosting door True

Programmeren niet langer een ambacht

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.  

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/6042611). © Jaarbeurs IT Media.
?

Partnerinformatie
 

Reacties

Ik ben het niet helemaal eens met de manier waarop e.e.a. wordt beschreven.

In het "ouderwetse manier van werken" wordt in een verhaal gehouden hoe het in de oude wereld werkt... en dat is wat gechargeerd waterval beschreven, en wordt neergezet als het Hades.
In het "moderne manier van werken" wordt er (nu ook even gechargeerd) een 4GL/5GL manier van werken geschetst, die als Walhalla wordt voorgesteld.

En dat terwijl er ook een tussenweg is. Ten eerste wordt voorbijgegaan aan het feit dat bij voldoende juist ontwerpen van de applicatie hele herverbouwingen ala Biereco kunnen worden voorkomen. Maar dit vergt tijd (en dus geld), en wordt in de meeste gevallen door het management verboden ("dat gebeurt nooit", "je hebt mijn garantie dat dit niet tegen jullie gebruikt gaat worden", "ik zorg wel voor de dekking hiervoor", etc.). En als het toch gaat gebeuren (en dat gaat het, dat hebben de ITers al voorspeld voordat ze door het management werden overridden), dan krijgen de ITers de schuld, want dat zijn cowboys.

In de jaren '90 van de vorige eeuw was er ook een hele opkomst van 4GL talen. Die zouden op functioneel niveau beschrijven wat er moest gebeuren en programmeren feitelijk overbodig gaan maken.

Nu bijna 30 jaar later is er van die tools weinig meer te horen en zijn we keurig weer "gewoon" gaan programmeren. De talen zijn krachtiger geworden, maar de 4GL talen zijn eigenlijk zelden nog in gebruik.

En kan de auteur ons vertellen hoe die aanpassingen van de laatste alinea zullen worden gemaakt? Ook als die slecht worden uitgevoerd zal het er op uitdraaien dat het rookkanaal opnieuw moet worden aangelegd.

Hadden we nu net infra as code, anders ben je niet flexibel..
Nu moet de code ook al weer low. Die introduceert alleen maar menselijk fouten, zo lezen we.
Niet code maar modelleren dus : Het maken van een virtuele blauwdruk voor de specifieke bedrijfsprocessen.
Maar die bedrijfsprocessen moeten natuurlijk ook weer op de schop, anders anders ben je niet innovatief en win je geen prijzen.

IT is niet goed of het deugt niet.
Gezien de enorme vraag uit de ICT markt lijkt er vooralsnog een tekort aan menselijk fouten te zijn.

Een oplossing voor dit was toch CASE? https://en.wikipedia.org/wiki/Computer-aided_software_engineering
Ik heb gewerkt voor Cayenne, daar maakne ze al in de jaren 90 die tools. Ik ben zelf geen ontwikkelaar maar waarom wordt dit dan niet (meer) gebruikt?

MDE (Model Driven Engineering) bestaat toch ook al decennia?

Wat Robert van der Linden beschrijft als 'Programmeren oude stijl' is inderdaad hoe het 30 jaar geleden gebeurde, maar vandaag de dag gebeurt het niet meer zo. Er worden geen stapels papier meer geproduceerd waar eindgebruikers een handtekening onder moeten zetten. Tegenwoordig wordt er software ontwikkeld in sprints van 2 weken: elke 2 weken wordt er werkende software opgeleverd (en gedeployd) die business waarde toevoegt en waarop meteen feedback gegeven kan worden. Dat voorkomt de taferelen die 30 jaar geleden voorkwamen.

Het hangt er een beetje vanaf wat je onder programmeren verstaat. Ik stam nog uit de tijd dat we hexadecimale code moesten kloppen om iets werkend te krijgen. Omslachtig en arbeidsintensief? Absoluut!!! Maar je dacht in ieder geval wel over een aantal dingen na voordat je aan de slag ging, immers, je wilde niet nog een keer alles uit moeten tekenen en tellen (of het nog wel in het geheugen paste).

En dat laatste mis ik wel eens; Agile en vergelijkbare methodieken hebben absoluut hun charmes maar doordat er vaak korte termijnkeuzes gemaakt worden (immers, de sprint duurt maar 2 weken en dan moet het af zijn) wordt er nog wel eens technical debt geïntroduceerd en zie ik veel keuzes gemaakt worden die men, als men wist wat er een paar sprints verder nodig zou zijn, anders gemaakt zouden zijn. Je hoeft niet alles vooraf in beton te gieten, maar zeker bij projecten waar hard- en software, al dan niet gecombineerd met embedded systemen, gebruikt wordt, zul je toch echt e.e.a. vooraf vast moeten leggen. Iedere 2 weken nieuwe hardware borden of mechatronica omdat je er tijdens deze sprint achterkomt dat het toch net iets anders moet is simpelweg niet haalbaar.

Hogere generatie talen, en model based development maken het leven een stuk makkelijker, maar ergens moet iemand nog steeds de vertaalslag maken van het model naar de nullen en enen die de hardware begrijpt. Voor de mensen die dat kunnen realiseren, is programmeren mijns inziens nog echt een ambacht.

Blauwdruk = synoniem voor architectuur, het raamwerk waarbinnen eea past. Dat hadden we dertig jaar geleden ook al. Maar heb zo ondertussen toch wel de indruk dat het daaraan schort: een goede architectuur, toekomstvast en goed gedocumenteerd met helder wat de scope, beoogd gebruik, verwachte levensduur en aanpasbaarheid is.

Wat ik nogal eens mis is de simpele regel: eerst denken dan doen.
Om het even met welke methode van programmeren

Geen enkele methode kan de kwaliteit van de software verbeteren, het gaat altijd om de kundigheid en vaardigheden van de ontwikkelaars. Een slecht ontwerp en slechte systeemanalyse levert slechte code op. Dat kan Agile/scrum ook niet voorkomen. Het enige voordeel is dat missers in een veel eerder stadium zichtbaar worden en kunnen worden bijgestuurd.
Bij hergebruik van code zoals bij object oriënteer programmering, Building Blocks en de 4e en 5e codegeneratoren waren de verwachtingen even hoog, maar dat is inmiddels ook een stuk minder succesvol gebleken. Zo zal het met Agile/Scrum ook gaan, het is een tijdelijk verschijnsel.
Programmeren blijft altijd voor een groot deel ambachtelijk werk. De grootste investeringen zitten namelijk in de interfaces en de verwerking van de data in de gewenste functionaliteit van de te bouwen systemen.
Tegenwoordig is gewenste functionaliteit in applicaties sterk gericht op businessprocessen, dat is een droge verandering ten opzichte van vroegere bedrijfsvoering dat mer gericht was op afdelingstaken en rapportages.
Een complex van op elkaar aansluitende businessprocessen is net als het componeren van een muziekstuk. Er zijn oneindig veel mogelijkheden en variaties mogelijk.
Het artikel is daarom een theoretische idealisering van een methode in de huidige tijdgeest.

Zoals wel vaker word duidelijk weer eens vergeten dat ict uit meer bestaat dan dotnet rommel in de cloud bij elkaar scrummen.
Zodra er niet een heel framework beschikbaar is dat alle uitdagingen voor de studentprogrammer wegneemt of er gevraagd wordt om (meestal ook nog vrij basale) functionaliteit zelf te implementeren haken de jongetjes direct af.
Het is ondertussen al ruim twintig jaar geleden toen men voorspelde dat met de 4e generatie programeertalen iedereen in notime een programma in elkaar kon zetten.
Momenteel zijn de recruiters echter nog steeds naarstig op zoek naar dat talent dan voor een appel en een zachtgekookt ei een leuke webinterface of Android App bij elkaar kan klikken.

Dagelijks stel ik vast dat programeurs (ongeacht de gebruikte buzzword methodiek) het ernstig ontbreekt aan basale kennis.
Zodra iets meer knowhow van de werking van hun favoriete compiler is vereist of basale kennis van de werking van een computer gaat het direct fout.
Allemaal issues die je bij het tiepen van BI-software of een webbased gadget niet zo snel tegen komt maar ik veronderstel ook niet dat Robert van der Linden daar op doelt.

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.

Jouw reactie


Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren

Je naam ontbreekt
Je e-mailadres ontbreekt
Je reactie ontbreekt
Computable Expert
Robert van der Linden

ir. Robert van der Linden
CEO, Thinkwise. Expert van Computable voor de topics BPM, Development en Digital Innovation.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×