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.
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.