Software doet bijna altijd wat het moet doen. Soms doet de software het niet, dan kan je even niet bij de webpagina van een leverancier. En heel soms maakt de software er een potje van, dan verandert ineens zonder aanleiding het saldo op je bankrekening. Een paar dagen geleden overkwam dat de klanten van een grote Nederlandse bank. Het gevolg: veel ophef, veel emotie, veel imagoschade voor die bank.
Wat was er nu eigenlijk aan de hand? We mogen hopen dat de organisatie zelf inmiddels de oorzaak achterhaald heeft. Op haar website spreekt de bank over ‘een technisch probleem in het boekingsproces’. Voor de buitenwereld blijft het gissen wat dat betekent. In het 8-uur journaal van donderdag 4 april deed hoogleraar informatica Jan Friso Groote een poging:
‘Miljoenen regels oude code met daarin nog duizenden fouten, niemand die meer precies weet wat die regels code doen. En dan moet het soms wel mis gaan.’
Een interessante observatie. Veroudering van code houd je niet tegen, de tijd schrijdt voort. Veroudering van mensen ook niet. It-medewerkers met kennis van zaken gaan met pensioen of gaan ergens anders werken. Een proces dat zich sluipenderwijs voltrekt. Totdat je als organisatie op een onverwacht moment hardhandig geconfronteerd wordt met de gevolgen.
Wat we zien gebeuren komt veel vaker voor, alleen (gelukkig) niet vaak met zo verstrekkende gevolgen. De aanwezigheid van fouten in code, de afnemende kwaliteit van code en kennis over die code (in documentatie of hoofden van mensen) staat in de it bekend onder de term ’technical debt’. Een schuld die met het verstrijken van de tijd steeds groter wordt, als je er niets aan doet.
De problemen van afgelopen week lijken daarmee gekwalificeerd te kunnen worden als een ‘gevalletje technical debt’. Had dit nu voorkomen kunnen worden? Dat zal ik niet zonder meer beweren. Maar, het zou mij niet verbazen als de bank in het verleden onvoldoende haar technical debt heeft gemanaged. Want daar komt het op aan: technical debt is op zich niet onoverkomelijk (en zelfs acceptabel), maar je moet het wel goed managen. Dus tijdig oude software vervangen, tijdig het weglekken van kennis opvangen, et cetera. Op dat vlak kunnen banken, net als veel andere organisaties, wellicht nog wat verbeterslagen maken.
Jacob Brunekreef
Senior adviseur en trainer softwarekwaliteit
Inspearit en Cibit Academy
Reactie van de auteur. Wat ik heb willen zeggen: It wordt steeds complexer, steeds meer van vitaal belang voor de maatschappij. Maar, aan de andere kant, wordt binnen veel organisaties it gezien als ‘commodity’ – iets dat gewoon z’n werk moet doen en niet veel aandacht moet vragen. In dat spanningsveld is het managen van technical debt een uitdaging die niet altijd voldoende aandacht krijgt. Of dat hier ook het geval was? Ik sluit me aan bij de oproep aan ING om openheid van zaken te geven. Zodat iedereen kan oordelen en er van kan leren.
@Jacob Brunekreef: Sympathiek dat je reageert! Zeker omdat er nogal wat kritiek tussen staat, onder andere van mij, daarom hulde!
Ik sta helemaal achter je reactie. Het is alleen jammer dat ING dan gebruikt wordt om de aandacht daarop te vestigen, effectief is het zeker gezien de reacties, maar niet sympathiek. Daarnaast zijn er wel wat meer dingen op aan te merken dat zoals PaVaKe schrijft ‘dat software er een potje van maakt’.
Ik ben benieuwd naar een volgend artikel waarbij je meer in gaat op de inhoud van je reactie. Mijn aandacht heb je 🙂
Nog even een reactie.
@JacobBrunekreef Wat je hier schrijft is al iets anders en daar kan ik me beter in vinden. Ben het eens met @henri dat de situatie bij de ING gebruikt (misbruikt) is voor het doen van statements over software die in dit geval misplaatst zijn. Dat vond ik kwalijk. Ik geloof niet eens zo zeer dat software als commodity beschouwd wordt, ik denk eerder dat de mens als commodity beschouwd wordt. Of het is dat je denkt door meer mensen ertegen aan te gooien je projecten kan versnellen of verbeteren of dat technici die applicaties maken, beheren en systemen beheren zomaar inwisselbaar zijn. Continuiteit op dit gebied lijkt mij belangrijk voor de kwaliteit van applicaties en systemen.
@Technicus Volgens mij noemde @PaVaKe dit ook al, de tijd die in het voordeel werkt en in software op leeftijd alle ellende er tzt wel uitgehaald is. Inderdaad, dat traject heeft nieuwe software nog niet doorlopen. Ook tijd hebben voor ontwikkeling helpt.
@maarten Ik hoop ooit hier nog iets over te schrijven, de Agile filosofie en de Scrum (Lean, Kaban,…) methode voor het begeleiden van ontwikkeltrajecten. Je geeft al aan dat de uitvoering hiervan al vragen oproept, dus naast dat vraag hoe de software te ontwikkelen is er ook nog de vraag is hoe het ontwikkelproces in te richten met Agile Scrum etc methodes. Nieuwe abstracties, nieuwe vragen en nieuwe rollen. Ik begrijp wel de achtergrond: aan een kant dat ontwikkelen van software een continu proces is waarbij voortschrijdend inzicht een rol speelt en aan de andere het nodig is voor de opdrachtgever vat te houden op de voortgang. Maar om dat op deze manier te formaliseren en micromanagement tot doel te maken? Zelf heb ik gezien dat voor een redelijk overzichtelijk project de scrum masters met bosjes werden binnengereden en leidend zijn. Het kost een hoop geld en de verkeerde mensen worden belangrijk. Door de technici die ik ken wordt het als een gruwel ervaren, gedegregadeerd tot domme uitvoerder. En dan die bizarre rituelen, zo ken ik een technicus die ieder dag met een standup meeting begint, alleen tegen de scrummaster mag praten om vervolgens te eindigen met de groepsyell. De padvinderij is er niets bij vergeleken. Praten met andere belanghebbenden is verboden, dat mag alleen via de scrummaster (leve het informele circuit!). Ik ga dan liever voor een meer basale aanpak met het liefst niet te veel mensen en rollen waarbij je je wat kan voorstellen: projectleider, technisch projectleider, project manager, ontwikkelaar, tester, informatie analist en documentatie deliverables (buiten de software) die welliswaar uit de oude doos zijn (bv reguirements document, functionele specs, technisch ontwerp, architectuur plaatje, user manual, operational manual) maar nog prima voldoen. Maak er niet meer van dat het is. Ik realiseer me dat het misschien vechten tegen windmolens is want ik zie dat het gemeengoed aan het worden is en er een hele industrie van opleidingen en certficeringen is ontstaan. Je voorbeeld van 10 chefs in een kano met 1 roeiende indiaan vind ik mooi en ook hierop van toepassing. Aan de andere kant als je er met zijn allen in gelooft komt er ongetwijfeld iets uit. Voor vrije jongens is het niets.
Nu de ontkoppeling van de ING storing is gemaakt, wil ik ook nog wel iets toevoegen:
Er is een verschil te maken tussen eenvoudige UNIX tools en complexe, organisch gegroeide bedrijfssoftware. Dat een tool na verloop van tijd foutvrij is en volledig begrijpbaar herken ik. Ook weet ik uit mijn eigen achtergrond als SW-ontwikkelaar dat in complexe code allerlei kleine, bijna verborgen afwijkingen die op het moment van implementatie logisch lijken, maar jaren later voor een probleem kunnen zorgen. En zo heb ik direct een beeld bij de ’technical debt’ waar Jacob het over heeft.
Je kunt je daartegen wapenen, maar dat vergt defensief programmeren, tussenresultaten controleren en valideren. 100% dekkend kun je daarin niet zijn. En dus begin je technical debt op te sparen…
Een verlate reactie, maar wie het denkt te beweren dat code zou kunnen verouderen heeft blijkbaar geen benul van software ontwikkeling.
Software is immers een momentopname van de abstracte gedachten van de mens. Of liever gezegd de meeste software. Er zijn al diverse prototypes gemaakt van zelflerende software maar of dit ooit bij financiele instellingen gebruikt zal worden is vooralsnog niet aannemelijk.
@Lex: Ja, maar wie maakt die code dan ook complex?
K.I.S.S. is een bekende uitdrukking binnen de IT en staat voor “Keep it simple, Stupid!”
Ook Schwartz schrijft iets in zijn boek “Learning Perl” over “readability” en dat je leesbare code moet schrijven, maar goed zelf zie al vaak dat nodes de vreemdste naampjes krijgen alsof het door bijvoorbeeld een botanicus bedacht is.