Een berucht artikel, 'Why software fails' uit 2005 beschrijft dit in detail. Het is treurig te zien dat er nog niet veel veranderd is in de afgelopen vijftien jaar. In deze opinie belicht ik twee van de belangrijkste redenen voor het falen van softwareoplossingen:
- Unrealistic or unarticulated project goals: de strategie, aanpak en doelstellingen zijn niet duidelijk geformuleerd
- Badly defined system requirements : de wensen en eisen voor de oplossing zijn niet goed in kaart gebracht
Beide redenen zorgen ervoor dat je er op een laat moment in het traject achter komt dat de software niet brengt waarvoor het eigenlijk bedoeld was - en kun je waarschijnlijk grotendeels opnieuw beginnen. Een dure grap dus.
Platformstrategie en aanpak
Het inzetten van een low-code-platform om daarop maatwerk te realiseren is een strategische keuze voor elke organisatie. Maar met het aanschaffen van het platform is maar een klein hobbeltje genomen. Met welk doel gaan we dit platform inzetten? Welke leidende principes hanteren we? Welke bedrijfsdoelen gaan we helpen behalen? Hoe past het in het applicatielandschap en hoe gaan we om met informatiearchitectuur? Hoe gaan we deze verandering binnen de organisatie managen? Hoe meten we het succes?
Bij veel organisaties zien we nog steeds dat de it-afdeling hier een leidende rol speelt, terwijl het allemaal om business-oplossingen gaat. De business wenst zich te onderscheiden van de concurrenten en wil digitaal innoveren. Om zo een groter marktaandeel te behalen of de marges te verbeteren. Het innoveren van business-processen en daarmee verregaande optimalisatie door te voeren is iets wat niet thuis hoort in de 'systems of record'. Dat zijn vaak robuuste, administratieve applicaties die ook eigenlijk commodity zijn. Steeds vaker zijn dit saas-applicaties. Iedereen gebruikt dezelfde.
Waar je het onderscheid kunt maken is in het slim aan elkaar koppelen van deze applicaties en cloudservices. Door data te verzamelen en verrijken en nieuwe inzichten te vergaren. Door het inzetten van kunstmatige intelligentie. En op de persona’s gerichte maatwerk-apps, die precies doen waar de betreffende persoon in het deel van het bedrijfsproces behoefte aan heeft. En liefst zonder al te veel in- of over te typen. Laat de gecombineerde data het meeste werk voor je doen.
Fouten gemaakt in strategie en architectuur (business-, applicatie- en informatiearchitectuur) kunnen dure gevolgen hebben. Hoe eerder je in het software voortbrengingsproces fouten weet te vermijden, hoe goedkoper het is. Zoals in het bovengenoemde artikel zo mooi is verwoord: als je een breifout hebt gemaakt en daar pas veel te laat achter komt, kun je bijna helemaal opnieuw aan de trui beginnen. Daarmee gaat veel tijd en geld verloren.
Het belangrijkste onderwerp om tot een goede strategie, aanpak en doelstellingen te komen is om workshops met de juiste stakeholders te organiseren. Begin hierbij altijd met een workshop die bepaalt welke stakeholders er precies nodig zijn en zorg ervoor dat ze genoeg tijd beschikbaar hebben. Als dit niet zorgvuldig gebeurd, is de kans op falen verderop in het proces veel groter.
User centered design
Als je het aan de eindgebruikers van softwareoplossingen vraagt hoe dingen beter kunnen, weten ze het meestal wel. Of, denken ze het te weten. De kunst is om de juiste gebruikers bij elkaar te krijgen en er naast te gaan zitten tijdens het uitvoeren van hun werkzaamheden.
Maar daarnaast is het belangrijk om van proceseigenaren te weten te komen hoe processen nu het best gedigitaliseerd en geoptimaliseerd kunnen worden. Vaak wordt nog gedacht in oude oplossingen; 'in het huidige systeem gebeurt het zo'. Een gebruiker is in principe maar een klein radertje in het geheel, en heeft vaak geen zicht op het grotere doel van zo’n proces en hoe dingen echt verbeterd kunnen worden. Om echt innovatieve functionaliteit toe te voegen. Om die klant echt beter te kunnen gaan bedienen.
Er wordt nog veel te vaak inside out gedacht. De echte why (de vraag achter de vraag) is moeilijk te achterhalen. Dat vergt creativiteit van de 'user experience' (ux) designer. Het draait tegenwoordig om customer-centric ux en niet meer om organization-centric ux (zie ook 'How ux is transforming business' in Forbes). En het vertalen naar goede requirements is echt wel een vak, waar dit soort mensen goed in getraind is en veel ervaring mee heeft. Het zijn vaak niet eens 'techneuten'. Door eerst de gebruikersinteractie en procesflows uit te tekenen en eventueel in een prototype te gieten, kan er al heel snel met eindgebruikers en proceseigenaren afgestemd worden of het aan de eisen en wensen voldoet. En of het inderdaad een verbeterd proces oplevert.
Eigenlijk begint daar het change proces al; iedereen moet worden meegenomen in dit optimalisatieproces. Met de ontwikkelaars in het devops-team wordt vervolgens besproken of het technisch haalbaar is. Voordat er ook nog maar een regel code geschreven is. Dit kan allemaal prima gecombineerd worden met een agile aanpak, waarbij er met elke sprint weer waarde wordt toegevoegd. Op deze manier is fail fast mogelijk, en kan het in de volgende sprint bijgestuurd worden. Zo wordt het realiseren van innovatieve software oplossingen goedkoper en krijg je echt precies wat bijdraagt aan de in de strategiefase bepaalde doelstellingen. Doelstellingen die uiteraard ook customer centric moeten zijn!
Reacties
Mooi verhaal Gijs. Ik herken veel van wat je schrijft.
Wat ook de in de afgelopen 20 jaar is gebeurd is dat met name die organisatie landschapsbeschrijvingen heel lastig zijn te communiceren. Het is nogal wat om wet- en regelgeving, functionele eisen en wensen, architectuurprincipes en standaarden, organisatieprocessen (niet verwarren met ITIL, dat hoor ik nou al zo vaak), producteigenschappen, functionele decomposities naar bedrijfsfuncties, werkinstructries, proceslogica, organisatielogica en uiteindelijk komt daar de ICT met zijn lage die in een technische decompositie naar ux, integratie, businessrules, procescontrol en uiteindelijke manifeste code in een overzicht inzichtelijke te maken.
Ik worstel daar mijn hele leven al mee en meerdere met mij. In het huidige tijdsbestek moet alles zogenaamd snel snel (vaak zonder enige concrete reden, omdat men zich geen houding kan geven) en vaak zie ik dat de nut- en noodzaak om een compleet organisatie-landschap te visualiseren en daarmee inzichtelijk te maken compleet genegeerd. De kunst van het over de schutting bij een ander vakgebied kijken is blijkbaar erg lastig. Het heeft ook te maken met typisch menselijk eigenschappen: niet in mijn keuken kijken. Het zou wel eens een zooitje kunnen zijn en dat is het vaak ook. Ook bij ICT hoor. Vraag een gemiddelde ontwikkelaar maar met het bijhouden en opleveren van documentatie. Antwoord: hier heb je de code (die herhalen ze dan in comment statements) of hier heb je de bijbehorende user story bij deze code.
Er moet nog heel veel water door ik weet niet hoeveel rivieren stromen, willen we dit hardnekkige probleem kunnen tackelen, zodat mensen gaan inzien dat complexiteit pas een geaccepteerde abstractie wordt zonder dat daar allerlei meningen zijn. En ik snap het wel. Niemand zal een discussie voeren over hoe een auto in elkaar gezet wordt, dat is tegenwoordig een complex apparaat geworden. Ja er wordt wel eens wat geroepen, maar uiteindelijk koop je dat ding en gaat ermee rijden en je verwacht dat hij ook doet wat je er enigsinds van verwacht.
Waar we het hier over hebben, is hoe een organisatie een concrete verandering kan doorvoeren. Vervelend genoeg zijn de mensen met wie deze verandering tot stand brengen op twee manieren betrokken bij de verandering. Wat betekent het voor mij in mijn dagelijks werk (en wat stelliger: heb ik nog wel werk) en wat kan ik bijdragen aan die verandering. Daar kom je volgens mij tot de kern van de zaak: willen ze echt de verandering en zijn ze in staat deze verandering vorm te geven.
Waar 40 jaar geleden uiteindelijk veel organisaties vonden dat projecten (ik noem het bewust geen ICT projecten, die bestaan voor mij niet) veel meer door de "business" (verzonnen term van ICT-ers!) moesten worden getrokken, want het ging toch om doelen en resultaten in de business, kom ik daar nu van terug. Stelling: ik ben niet meer van mening dat een gemiddelde afdeling zelfstandig een complexe organisatieverandering kan managen naast de going concern taken. Dat vereist een dermate hoog kennisniveau over al die zaken die aan het begin van dit epistel staat en die met name in relatie te brengen. Deze kennis en kunde is echt niet aanwezig binnen lijnorganisaties. Ik maak me daar zeker niet populair mee.
De eerste stap is maar eens een gemeenschappelijke taal ontwikkelen zodat we elkaar op dat grote (organisatie)schaakbord gaan vinden en vandaaruit de discussie gaat voeren wat je daar voor expertise voor nodig heeft. Ik zie voor de (enterprise)architect een grote rol weggelegd en voor een nieuwe rol die op het detailniveau van het organisatielandschap kan acteren en heel dicht bij de lijnafdeling zit (het liefst onderdeel daarvan is). Ik ben nog aan het verzinnen hoe je zo iemand moet gaan noemen.
Ach heren, kies dan voor een biologisch groeimodel, neem een klein plantje, geef het aarde, water en licht en laat het gekontroleerd groeien.
En vergeet "komplex" denk aan KISS, steeds opnieuw. Dan krijg je de neuzen vanzelf in dezelde richting.
Klinkt toch goed?
vroeger was alles beter
ook de requirements
eerste stap van de waterval
alleen dat deugde ook weer niet
het moest agile
want requirements zouden we pas weten na een protoype
een minimum viable product
het plantje van jantje
"iedereen moet worden meegenomen in het optimalisatieproces"
over "Unrealistic or unarticulated project goals" gesproken
gijs geeft een nieuwe interpretatie aan het begrip "low code"
waarde wordt toegevoegd "Voordat er ook nog maar een regel code geschreven is" ;-)
stellen dat "dat er nog niet veel veranderd is in de afgelopen vijftien jaar"
en dan de oplossing van het requirements afstoffen en oppoetsen
maar dat dan weer mergen met agile/devops/sprint/innovatief/failfast/customercentric
ict is een dure grap
Daan Rijsenbrij heeft over het vergelijkbare onderwerp, maar dan bij de Nederlands overheid dit stuk recent gepubliceerd.
https://itexecutive.nl/wp-content/uploads/2020/09/Kanttekeningen-Digitalisering-Overheid.pdf
Een aantal dingen die in het artikel genoemd zijn kom je ook daar tegen.
Gijs,
Het is goed om achterom te kijken door te verwijzen naar een artikel uit 2005 maar 'All People Seems To Need Data Processing' gaat om een stack die door Internet gewijzigd is. Eveneens geldt dat voor samenwerkingen welke door de Systems of Engagement veranderd zijn want een moderne interactie met de data wordt gedreven door alle mogelijkheden van Internet waardoor data 24/7 toegankelijk is voor gebruikers. De Systems of Record gaan vooral om het vastleggen van de informatie en Salesforce is dus een systeem voor het vastleggen van de klantgegevens, Github een System of record voor de code en ServiceNow voor de IT-operaties om een paar voorbeelden te geven waar in 2005 niemand nog van gehoord had.
De essentie van het zeggen wat je doet, doen wat je zegt en dat bewijzen is tenslotte niet veranderd als het om de administratieve verplichtingen van het vastleggen gaat. En vol verwachting klopt hierin ons hart als het om innovatieve platformen gaat waarin overtreffende trap de Systems of Intelligence zijn met daarin een discussie over situationele of contextuele synthese van data en metadata als het om bronnen zoals de Systems of Record en de Systems of Engagement gaat. Want terugkijkend naar 2005 leefden we vooral in angst voor dodelijke vogelgriep en zeiden we 'NEE' tegen de Europese grondwet.
Ik denk dat MicroFrontends, zelfstandig werkende componenten in een georchestreerde interface, een oplossing kunnen bieden voor gestelde problematiek. Door verdeel-en-heers, langs slim gekozen lijn van geisoleerdheid en duidelijke afgebakende verantwoordelijkheden of domeinen of functionele contexts krijg je een groot aantal agile en makkelijker aan te passen applicaties die je eenvoudig kan integreren tot een groter geheel. Dat is veel meer agile werken binnen de Enterprise context dan sociale consensus bereiken door het verfijnen van requirements voordat daadwerkelijk bouwen begint, wat dit artikel lijkt te suggereren, en wat voor mij voelt als terug naar "Big Design UpFront" met alle gebruiksonvriendelijke oplossingen die uit die methodologie zijn voortgekomen? MACH - MicroSevices, API first (message protocol first), Cloud, Headless (componenten) gaat volgens mij niet alleen over de applicatie architectuur, maar zeker ook over de organisatiestructuur, het toekennen/delegeren van verantwoordelijkheden aan groepen mensen / teams en de wijze waarop die onderling samenhangend toch los van elkaar samenwerken?
Ik denk dat MicroFrontends, zelfstandig werkende componenten in een georchestreerde interface, een oplossing kunnen bieden voor gestelde problematiek. Door verdeel-en-heers, langs slim gekozen lijn van geisoleerdheid en duidelijke afgebakende verantwoordelijkheden of domeinen of functionele contexts krijg je een groot aantal agile en makkelijker aan te passen applicaties die je eenvoudig kan integreren tot een groter geheel. Dat is veel meer agile werken binnen de Enterprise context dan sociale consensus bereiken door het verfijnen van requirements voordat daadwerkelijk bouwen begint, wat dit artikel lijkt te suggereren, en wat voor mij voelt als terug naar "Big Design UpFront" met alle gebruiksonvriendelijke oplossingen die uit die methodologie zijn voortgekomen? MACH - MicroSevices, API first (message protocol first), Cloud, Headless (componenten) gaat volgens mij niet alleen over de applicatie architectuur, maar zeker ook over de organisatiestructuur, het toekennen/delegeren van verantwoordelijkheden aan groepen mensen / teams en de wijze waarop die onderling samenhangend toch los van elkaar samenwerken?
Ik ga nog maar eens water geven, dat is niet zo duur Dino.
Wat ik positief beoordeel is dat artikel en reacties mijn woordenschat op gebied van marketing kretologie toch weer vergroot heeft, Dankuwel heren!
Jan,
Fijn dat je woordenschat weer wat vergroot is, terugkijkend hoe de technologiemarkt zich in de loop van de tijd heeft ontwikkeld kent elk tijdperk namelijk zijn eigen dominante 'marketing' term welke mede resoneert door de dominantie van bepaalde bedrijven die veel geld besteden aan marketing:
1970–1985: Het "Silicon" - tijdperk (bijv. Intel, opgericht in 1968)
1975–1990: Het "Informatie" - tijdperk (bijv. Oracle, opgericht in 1977).
1985–2000: Het "Netwerk" - tijdperk (bijv. Cisco, opgericht in 1984)
1995–2010: Het "Internet" - tijdperk (bijv. Netscape, opgericht in 1994)
2000–2015: Het "SaaS" - tijdperk (bijv. Salesforce, opgericht in 1999)
2015-2030: Het "Systems of Intelligence" - tijdperk (hedendaagse digitale transformatie)
Heel wat IT-ers zullen de komende weken de geraniums op de vensterbank water gaan geven, de uitdrukking van het nietsdoend achter de plantjes zitten zal je waarschijnlijk ontgaan maar als we onderling samenhangend maar toch ook los van elkaar gaan werken waar Thijs Cobben het over heeft dan is er een ecosysteem nodig. De bovenstaande opsomming geeft je een idee hoe afgelopen 50 jaar 'productieplatformen' zich hebben ontwikkeld van stand-alone
PC's tot de anytime & anywhere netwerkdevices aan de randen van de architectuur. Thijs Cobben heeft het over de zelfstandig werkende componenten in een georchestreerde laag wat dus naar mijn opine de Systems of Intelligence zijn binnen de digitale transformatie.
Ik wil je daarom wijzen op een verhaal over jagers en verzamelaars wat jezelf schreef in 2015 over het gebruik van metadata, het 'All People Seems To Need Data Processing' van het 7-laags OSI-model wordt omgedraaid met de belofte van AI. De moderne datasynthese gaat niet om (low)code maar het eigenaarschap van de informatie omdat hier de afgelopen 20 jaar een verdienmodel omheen is gebouwd. Oja, betreffende zaadjes zaaien in de grond van een ander schreef ik 2012 al dat de Dot.com economie veranderde in een Bedot.com economie als we de waarde van kennis onderwaarderen.
Oudlid, waarom kom je toch steeds met systemen aanzetten waar we behoefte hebben aan architectuur?
“Systems of Intelligence” is net zulke onzin als “digitale wereld”; het taalgebruik van de faalarchitecten.
Een begrip als ‘resonantie’ kun je wat mij betreft niet vaak genoeg herhalen, alleen al omdat je hiermee buiten de gebaande (en hier dus ook doodlopende) paden van het systeemdenken treedt.
In een reactie aan jou op 17 juni 2015 19:36 noemde ik de Systems of Engagement al “doodgewone onzin”, dus dit zijn inzichten die ik maar moeilijk tussen jouw oren krijg :-)
@jack, het kan jou niet vaag genoeg zijn, maar zoals Jan Schaefer al zei : "In gelul kun je niet wonen".
In architectuur kun je geen data verwerken.
Jack,
In de filosofie is een systeem een geheel van denkbeelden die zijn gebaseerd op bepaalde grondbegrippen en grondgedachten. Voor de IT geldt min of meer hetzelfde voor het begrip systeem als het om een samenhangende set aan soft- en hardware componenten gaat. Betreffende de paden van systeemdenken, alleen het genie beheerst het pad van de chaos want ordening is de drugs voor de massa.
Samenhang alias een onderlinge relatie geldt ook voor de 'betrokkenheidssystemen' zoals ik uiteen zette in mijn reactie van 18 juni 2015 over de interpretatie van de wedstrijduitslag als een doelpunt afgekeurd wordt door een buitenspel situatie. We moeten nu onze bek houden als dit gebeurt maar over de kunst van communicatie heb ik al eens gezegd dat het meer is dan het gesproken of geschreven woord.
Eén plaatje zegt meer dan duizend woorden en ik denk dat betreffende het verwachtingsmanagement iedereen bekend is met het boomschommel-beeldverhaal. Minder bekend zijn de Wasgij-puzzels waar verbeeldingskracht de oplossing brengt en je iets anders krijgt dan verwacht. Falen is dan het nieuwe succes, welkom in 1984;-)
Oudlid, je eerste alinea is alvast scherp neergezet en correct. Eén van de bekendste systeemdenkers in het tijdperk van de Verlichting was Hegel, wiens dialectisch idealisme vervolgens door Marx werd omgebogen naar een dialectisch of historisch materialisme.
Nou raad jij niet welke filosoof met Zijn en Tijd in 1927 het architecturale denken in de filosofie heeft ingevoerd. En terecht is de existentiefilosofie (niet te verwarren met existentialisme!) daarna ook wel een verbeterd marxisme genoemd.
Overigens zijn er wel meer mensen te vinden met kritiek op het systeemdenken:
“Systeemdenken is wat mij betreft zo’n oude manier van denken die, wanneer de schaal zich vergroot, zal falen in de omgang met complexiteit. De digitale wereld is nogal conservatief in haar eigen grondgedachten, ook als er buiten haar eigen kringen al genoeg ander denken te halen valt. De digitale wereld denkt momenteel nogal van binnen naar buiten, om het maar even zo te zeggen. In alle bescheidenheid: we moeten die wereld een blikverruiming gunnen.”
Jack,
Over Sein und Zeit van situationeel bewustzijn hadden we in 2015 een discussie omdat we in een ander tijdperk leven dan Heidegger en Hegel. Van de verlichting naar een (digitale) verheffing zullen we maar zeggen hoewel we inderdaad kunnen spreken van neo-Marxisme. Want kennis als toegepaste intelligentie heeft een gebruikswaarde in de vorm van arbeid maar ook een ruilwaarde in de vorm van algoritmen. En betreffende laatste is het bewezen dat een computer veel beter kan 'denken' in 2 kleuren op een schaakbord met 64 velden dan de meeste mensen. Maar de berekenbaarheid in de complexiteitstheorie gaat niet om filosofie maar wiskunde, een andere wetenschap.
Oudlid, dat jij hier van Neomarxisme spreekt past geheel binnen je wetenschappelijke (en materialistische) instelling. Zoals bekend presenteerde Marx zijn theorieën als wetenschap en niet als filosofie. Onder het motto: de filosofen hebben de wereld alleen maar geïnterpreteerd; nu komt het erop aan haar te veranderen. En de latere variant hierop: “in geouwehoer kun je niet wonen” (zoals Dino terecht opmerkt).
Nu maakte het marxisme wel onderscheid tussen een materiële onderbouw en een geestelijke bovenbouw (het maatschappelijk zijn dat het bewustzijn bepaalt), maar het heeft nooit kunnen verklaren hoe het bewustzijn (en daarmee ook de menselijke vrijheid) uit de materie is voortgekomen. Op dat punt kan existentiefilosofie dus een verbeterd marxisme worden genoemd.
De situatie waarin een mens verkeert is veel meer dan alleen maar een weerspiegeling of reflectie van de manier waarop mensen hun bestaansmiddelen voortbrengen (de economische en materiële verhoudingen van een maatschappij); pak de piramide van Maslow er maar weer bij.
Met je wetenschappelijke blik op de feiten ga je voorbij aan de waarheid die hieraan vooraf gaat. Voordat je van alles gaat beweren over een ding – “iets van iets” zeggen ofwel het constateren van feiten - is het ding al verschenen. Deze oorspronkelijke waarheid noemt Heidegger Aletheia (On-verborgenheid). Met dit begrip zijn verbonden: zijn, waarheid, ware kennis.
https://nl.wikipedia.org/wiki/Aletheia
Je idee dat kennis kan worden vormgegeven met algoritmen is een miskenning van de menselijke transcendentie.
Een discussie die mooi aansluit bij bovenstaande (vanaf 12:35):
www.vpro.nl/programmas/tegenlicht/kijk/afleveringen/2019-2020/herover-je-data.html
“De digitale wereld kan wel degelijk weer menselijk worden” (42:45).
Piramide van Maslow is me bekend en daarom wees ik op het idee van Marx als het om het kapitaliseren van kennis gaat, je kunt als kok gaan werken of als schrijver van recepten als we kijken naar cognitive piramide. Denk dat het bewustzijn over het materiële welzijn de essentie bepaalde van het communistisch manifest, het verenigen van de proleten ging om een sociale revolutie. De 'trancendentie' van Heidegger en Marx ging om het mobiliseren van de arbeiders als soldaten en de historie leert dat Duitse filosofen telkens een dure grap zijn.
Neo-Marxistische leer dat iedereen moet gaan studeren om zich te verheffen is prachtig alleen hebben we volgens economische leer van vraag en aanbod in de ruilmaatschappij meer aan de timmerlui die hebben leren 'hameren' dan filosofen die de spijkers er in proberen te ouwehoeren;-)
Waar ligt het probleem met software? In de taal.
Heb meer dan 30 jaar vanaf S38 tot en met IBM eServer in RPG en RPG Ile geprogrammeerd.
Ook +/- 10 jaar in Oracle PLsql
Was alsof ik lichtjaren teug ging in de tijd. Bij het begin van de oerknal.
Welke machine kan ook server zijn?
De IBM eServer.
Welke taal kan ook als PHP gebruikt worden?
RPG Ile.
Een machine moet een programmeurs omgeving hebben.
Wie heeft dat?
Visual Basic
IBM iServer.
Uitgebreide debugging mogelijkheden?
IBM eServer.
Moet programma's compileren en bij fouten een lijst met fouten produceren.
Wie heeft dat? De IBM eServer.
Syntax checking terwijl je code intoets ?
Wie heeft dat?
Visual Basic
RPG Ile.
Met welke taal kan men zijn eigen gereedschap maken?
Met RPG Ile
DSPJRN
De eServer legt de mutatie vast in een journal, Welk system doet dat?
Heb een programma gemaakt waarbij je de journal entry's op rubrieksnivo kunt zien
Als er een verschil is tussen de inhoud for en after, wordt dat aangeven
Kan een roll lforwards of backwards maken voor testen
Programmagenerator
1 regel met een paar parameters maak een compleet mutatie programma.
Lijst met subroutinestructuur. En nog meer.
De eServer met RPG Ile is de meest geavanceerde programmeurs omgeving. Maar IBM kan niet goed reclame maken.
Java en etc, zijn brabbel talen
Verschil maken tussen A en a leidt alleen tot fouten.
Het is een schande dat die brabbeltalen op school geleerd worden.
Als iedereen over zou stappen op de IBM eServer met RPG Ile ging de software ontwikkeling +/- 90% sneller.
Mijn ervaring met PLsql Oracle. Daar was dat allemaal niet mogelijk.
Heb een brief aan premier Rutte geschreven over de problematiek in softwareland.
Staat op:
www.hhsee.nl
Nu met pensioen.
Met vriendelijke groet,
Cor Olthuis