👑 Moet code van LLMs wel onderhoudbaar zijn?

Recent merkte iemand op dat de enige reden voor Clean Code, Design Patterns, SOLID, en dergelijke aanbevelingen is om te zorgen dat het mogelijk blijft om afgebakende stukken software te kunnen vervangen door een verbeterde versie. 🚀

Dat inzicht sprak mij aan, want dat is precies wat ik al jaren ervaar: Door software netjes te structureren blijft het mogelijk om de stroom nieuwe inzichten in de bestaande code in te passen. 🌈

En als het eenmaal chaos is, dan stagneert de evolutie tot het oplossen van steeds weer nieuwe bugs in plaats van het verder groeien van het systeem. 💩

Met de opkomst van generatie van code door AI (“Vibe coding” etc) krijg ik de indruk dat er een stemming ontstaat dat structuur minder belangrijk wordt. Een LLM is immers veel beter in het interpreteren van chaos dan mensen.

💡 Mijn mening is dat structuur te maken heeft met het systeem, en niet met de programmeur. Ook als de programmeur (veel) slimmer is, blijft de informatie opgeslagen in structuur een belangrijk ingredient voor evolutie. Niet alleen voor mensen, maar zeker ook als context voor een LLM.

🔮 Misschien is het sturen van de structuur van code wel het belangrijkste wat wij als als mens aan software bij kunnen dragen.

🏆 Of is verantwoordelijkheidsgevoel genoeg?

Laatst kwam ik een pleidooi tegen voor de noodzaak van een “Definition of Ready” voor startende Agile teams, gevolgd en een geleidelijke transitie naar een uitgebreide “Definition of Done” bij het groeien van de maturity. 🦄

De strekking was dat niet-Agile teams vooraf duidelijk moeten weten wat er verwacht wordt, en als er eenmaal Agile gewerkt wordt het vooral belangrijk is dat het werk compleet wordt afgerond voor we doorgaan naar de volgende taak op het bord.

Ik vind dit een fascinerende theorie, vooral omdat ik zoveel teams prachtige definities van beide smaken heb zien formuleren, om er vervolgens helemaal niets mee te doen. 🤡

Voor mij vallen beide checklists onder een gebrek aan verantwoordelijkheid van de teamleden zelf, en geven daarmee een extra zetje om te falen. Verantwoordelijkheid nemen en kleine stapjes zijn voor mij de werkelijke kern van Agile werken. In mijn ervaring ontstaan er daarna vanzelf borgingen die falen voorkomen. 🌈

💡 Mij lijkt het daarom belangrijker nóg kleinere taken op te pakken en onderling beter te communiceren. – De rest volgt vanzelf.

Meestal lossen we gewoon puzzels op!🧩

De mooiste puzzel heb ik ervaren bij TomTom, waar we 3D kaartmateriaal uit de centrale database verbouwden naar een wereldwijde legpuzzel die per stukje door auto’s wordt opgehaald en weer tot de nieuwste lokale kaart aan elkaar kan worden gelegd. 🗺️

De doorlopende wijzigingen in de bron kaart vertaalden we naar nieuwe efficiënte puzzelstukjes, die vervolgens weer naadloos in de wereldwijde legpuzzel passen. Zo kan elke auto doorlopend de nieuwste kaart aan boord hebben. 🧭

Zowel het mechanisme van deze puzzel als de infrastructuur om hem te produceren en te leggen heb ik als syteem architect samen met mijn team succesvol tot het TomTom AutoStream product ontwikkeld. 🚀

Een van mijn eerste projecten was een geluid & lichtshow op drie lokaties in Egypte. 🎵🔦

Een Borland Pascal applicatie in MS-DOS in de tijd dat Windows nog niet bestond. We stuurden zelfgemaakte hardware aan die surround geluid en een heftige lichtshow met lasers en projecties bestuurden. Wij waren er zelf erg van onder de indruk. 🤓

Ons versiebeheer bestond uit files op een gedeelde netwerkschijf, en ons proces bestond uit de eerstvolgende logische stap richting een werkend systeem. Ad-hoc, maar erg effectief. 🚀

Er is in de loop van de jaren veel veranderd, behalve mijn motivatie om mooie dingen te realiseren.