Voor de niet automatiseerders zal dit Blogje niet zo interessant zijn. Enige ICT kennis is vereist.
Al ruim 45 jaar ben ik programmeur en heb altijd programma’s geschreven volgens KISS (Keep It Simple Stupid) en daar ben ik succesvol in geweest.
De programma’s welke ik schreef konden altijd zonder problemen verscheept worden naar klanten en/of andere vestigingen van de Moedermaatschappij.
Waarom ? Leesbaarheid !! Vooral ook de accountants welke geregeld interne controle hielden waren daar door gecharmeerd.
Nadat ik ze een kleine inleiding had gegeven konden ze aan de hand van de programma listings (RPG) zelf zien wat er gebeurde en hoefden ze mij verder niet te storen.
Toen ik begon was er geen functiescheiding voor mij, en was ik eigenlijk systeembeheerder, projectleider, systeemanalist, systeemontwerper en programmeur.
De afdeling waar ik begon bestond buiten mij uit 3 operators welke de hele dag niks anders deden als; ingevulde formulieren (Orders, Journaalposten, Voorraadmutaties etc.) in te geven m.b.v. simpele data-entry programma’s, diverse batch-procedures laten lopen en papier wisselen. Ik kreeg de opdracht en de vrijheid om dit allemaal wat efficiënter op te zetten. Een geweldige opdracht en begon bij de boekhouding daar was de meeste winst te behalen. ik gaf mezelf de uitdaging om alles real-time te maken. Geen batch-procedures meer en alle informatie altijd up to date.
Mijn werkwijze (Prototyping Kiss) ging als volgt:
Systeemanalyse: Met een gebruiker gaan praten en ik hoefde eigenlijk maar 3 dingen te weten. Input, Output en Hoe kom ik tot de output (Berekeningen)
Systeemontwerp: Hierna ging ik een User-interface programmeren en dan samen met deze alpha versie terug naar de gebruiker om te kijken of alles naar wens was.
Programmeren: Hier ging ik de functionaliteiten aan de alpha-versie toevoegen en de bestanden ontwerpen en creëren. Dit resulteerde in een bètaversie.
Na een paar dagen schaduwgedraaid te hebben met de bètaversie (waar vrijwel nooit bugs uitkwamen) ging de rest ermee werken en konden de formulieren de prullenbak in.
Overzicht van het complete project (2 programma’s, 4 bestanden):
. Data entry programma met veel real-time informatie op het scherm zoals saldo’s en stamgegevens informatie.
. Een opvraagprogramma waarin legio boekhoud informatie opgevraagd kon worden.
. Een stambestand waarin diverse omschrijvingen stonden
. Een saldo bestand. Niet volledig genormaliseerd maar gewoon 12 maandvelden, met als sleutel Jaar(4 digits!)/Grootboekrekening/Kostenplaats/Kostendrager
– Een Journaalbestand. De gegenereerde journaalregels.
– Een beweging bestand waarin precies werd opgeslagen wat er ingevoerd werd.
Dit laatste was een belangrijk bestand omdat het alle gegevens bevatte van een transactieregel zodat je niets miste. Bovendien gaf dit de mogelijkheid om terug te gaan naar een bepaalde datum door deze data geautomatiseerd tegengesteld in te voeren. (Permanent of tijdelijk) tot de datum bereikt was.
De programmatuur was simpel, en te lezen als een boek, alles netjes overzichtelijk bij elkaar. Geen zoekplaatsjes van vele stukjes losse code, layers, definities etc.
Daardoor was het eigenlijk altijd Bug-vrij en zeer makkelijk aan te passen. Ook de vestigingen waarheen mijn systemen verscheept zijn hebben altijd zonder mijn hulp (De documentatie zat in de programma sources) aanpassingen kunnen maken. Bugs waren er simpel niet, anders zou ik het niet opgeleverd hebben (Er was geen tijdsdruk, heel belangrijk !!).
Ook de andere systemen (Order/Facturering, Voorraad, Debiteuren/Crediteuren, Inkoop budgettering, Verkoop budgettering, Kosten/Bedrijfsinformatie systeem en Buitendienst systeem) zijn foutloos is productie gegaan, en binnen een jaar had het bedrijf een automatisering waar iedereen zeer tevreden mee was. Het bedrijf heeft bijna 25 jaar op deze software gedraaid.
In die tijd was ik geen uitzondering, ik ontmoette ‘op mijn vele cursussen’ vakgenoten waar het net zo ging. Eenlingen met veel vrijheid van werken.
Zo was het vroeger, een tijd waarin de programma’s foutloos waren en programmeurs elkaars programma’s en bestandsorganisatie nog konden lezen.
Bugs waren erg zeldzaam, maar mocht er onverhoopt toch eentje opduiken, dan was dat in no time opgelost. Leesbaarheid en Simpelheid !!!!
Mijn eerste kennismaking met de kentering van het (in de praktijk allerbeste) Kiss systeem;
Omdat ik het op een gegeven moment heel erg druk kreeg met het schrijven van PC software, Interfaces Midrange<>PC en Interfaces naar een nieuw (Ingewikkeld) Extern systeem, werd er een bedrijf ingehuurd welke de bedrijfsinformatie software (Nu draaiende op het Midrange systeem) zou herschrijven voor het PC platvorm.
Een van de (onervaren) programmeurs kwam bij mij op de kamer zitten, en het viel me al snel op dat hij een nogal arrogant tegen me deed en me er vaak op wees dat ik niet programmeerde zoals zou moeten. Toen ik later een door hem geschreven rapport tegen kwam over mij zag ik dat ik compleet de grond in geschreven werd, mijn programmatuur was verkeerd geschreven, maar hun bedrijf zou dat wel even in orde maken.
Twee jaar lang zijn er 4 programmeurs aan de slag te gaan om een systeem te maken (die me in mijn eentje 2 weken heeft gekost) welke dezelfde informatie gaf als op de As/400 maar dit keer op PC platform. Het resultaat was zulke ongelooflijk complexe programmatuur en bestandsorganisatie dat ik er weinig vertrouwen in had.
Het weekend voordat dit onfeilbare/perfecte systeem life ging schreef ik thuis voor de lol een systeem welke exact hetzelfde (en nog wat meer) deed, maar dit keer op Web-platform. Het Intranet had ik bij mijn bedrijf al geïntroduceerd en iedereen kon daar op.
Zoals verwacht, de eerste dag dat het nieuwe systeem life ging, crashte alles, de programmatuur liep vast, de data was niet meer benaderbaar en aangezien de interactieve As/400 programmatuur uitgeschakeld was had niemand nog enige informatie.
Meteen kwam er een team van deze onfeilbare programmeurs om het recht te zetten, maar was na 2 dagen nog niet gelukt.
Op dat moment besloot ik om mijn Hobby project op het Intranet vrij te geven, en de reacties waren overweldigend. Iedereen had er toegang toe, alles zat er in, het was foutloos en betrouwbaar.
De Directie vroeg mij; Waarom ben je hier niet eerder mee gekomen ? Mijn antwoord; Ik heb het het afgelopen weekend pas gemaakt.
Het softwarebureau, welke mij zo wist af te kraken en in diskrediet probeerde te brengen werd verder terzijde geschoven. (En inmiddels Failliet).
Vrijwel zelfde ervaring in mijn laatste baan.
Jonge collega’s welke mij precies wisten te vertellen wat ik allemaal fout deed omdat ik niet programmeerde op de manier zoals hun dat geleerd hebben.
Bovendien wezen ze me steeds op hun opleiding maar dat maakt weinig indruk op me:
Ten eerste: Ervaring en Successtory’s zijn zo ontzettend veel en veel belangrijker !!
Ten tweede: De uren welke ik heb besteed aan studeren en cursussen volgen is een veelvoud van de uren welke hun tot nu toe in de ICT gestoken hebben.
Het grootste gedeelte van hun tijd waren ze bezig met het zoeken naar de bugs welke ze in hun te complexe programmatuur hadden gemaakt, en als ik een vraag had over iets dat niet duidelijk was voor mij, was dat vaak ook niet duidelijk voor hun.
Ook Windows en vele populaire apps zoals Pokemon Go barsten van de (hoe langer hoe meer) bugs.
De problemen bij overheden/bedrijven zoals de belastingdienst stapelen zich op, vanwege vertrekkende programmeurs welke onbegrijpelijke en buggy code hebben achtergelaten.
Waar gaat het dan Mis ? Dit is toch een slechte ontwikkeling !
Geen Kiss maar:
– Zo ingewikkeld, Cryptisch, Onleesbaar en Onoverzichtelijk mogelijk.
– En vooral geen overzichtelijk logisch verhaal, maar allemaal kleine stukjes programma’s welke naar elkaar verwijzen.
– Zoveel mogelijk afkorten, dus geen leesbare zinnen meer maken, maar inkapselen in allerhande leestekens.
– Afhankelijkheid van de diverse stukjes code onmisbaar maken, zodat ook meteen alles omvalt als er ergens iets mis gaat.
– Gebruik zoveel mogelijk technieken en talen in een project. Gewoon Java-script, J query, Angular, Share-point en C# in 1 project gebruiken.
Er zijn meerdere Oorzaken:
– Object georiënteerd programmeren, een buitengewoon slecht idee welke de onbeheersbaarheid/betrouwbaarheid van programmatuur op gang heeft gezet.
– Projecten vertragen door de vele meetings en het feit dat meerdere programmeurs, elk met hun eigen stijl aan dezelfde complexe programmatuur werken.
– Deadlines en opgelegde tijdschattingen. Hierdoor ontstaat ook nog eens stress welke de werksfeer en kwaliteit van de software niet ten goed komt.
En Juist doordat met de huidige programmatuur alles op 100+ manieren opgelost kan worden en er constant weer nieuwe zaken bijkomen lijdt dit tot veel overleg en uitleg van programmeurs onderling. (Vergelijk dit met een betrouwbare/leesbare taal als COBOL waar sinds 1960 tot heden slechts 6 versies van zijn verschenen)
En niet in de laatste plaats lijdt dit tot chaotische programmatuur, waarin enorm veel verschillende oplossingen te vinden zijn voor hetzelfde probleem.
Ik ben blij dat ik zo langzamerhand aan het eind van mijn werkbare leven ben, het is frustrerend om deze ontwikkeling te zien.
Ik hoop voor de toekomst dat we weer teruggaan naar KISS. Foutloos, Simpel en Leesbaar, dit is zo ontzettend belangrijk !!!.
Stop met deze waanzin, en ga weer terug naar de tijd toen je nog kon vertrouwen op computers !
Samengevat (Zen of Python):
Simple is better than complex.
Flat is better than nested.
Readability counts.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Aangezien ik nog veel meer wil vertellen en de blog niet te lang wil maken volgt er nog een deel 2 en 3.
2) Nog een aantal staaltjes van onnodige ingewikkeldheid welke ik in de praktijk heb meegemaakt.
3) Argumenten tegen Object georiënteerd programmeren en de huidig gangbare programmeertalen.
