CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

Stel je voor dat je een stad ziet groeien. Je zou kunnen tellen hoeveel bakstenen er elke dag worden gelegd, of je zou kunnen controleren of de gemeenteraad de regels heeft gevolgd. Maar er is een derde, interessantere manier om naar een stad te kijken: kijk hoe de gebouwen veranderen. Slaan mensen oude muren neer om een nieuwe kamer toe te voegen? Bouwen ze een nieuwe vleugel die aan de zijkant vastzit zonder het hoofdgebouw te raken? Veranderen ze gewoon een schakelaar om de verlichting aan te passen? Of verplaatsen ze simpelweg de meubels? In de wereld van software is dit precies de vraag die onderzoekers stellen. Software is niet alleen code; het is een levend systeem dat constant moet veranderen om nuttig te blijven. Als een systeem alleen verandert door zijn eigen muren af te breken, wordt het uiteindelijk een wankele, gevaarlijke bende. Maar als het verandert door nieuwe vleugels toe te voegen of schakelaars om te zetten, blijft het sterk en flexibel. Dit is de kern van "softwarekwaliteit"—niet alleen of de code vandaag werkt, maar of het kan blijven groeien zonder uit elkaar te vallen morgen.

Dit artikel introduceert een nieuwe tool genaamd CLEM (Change Localization and Externalization Measurement) om die vraag te beantwoorden. In plaats van alleen te tellen hoeveel code er is veranderd, werkt CLEM als een detective die observeert hoe ontwikkelaars een systeem repareren of bijwerken. Het sorteert elke wijziging in een van vier "persona's":

1. Modificatie (M): De "Sloopmethode". De kerncode direct aanpassen. Het is snel maar riskant, zoals een gat in een muur hakken om een deur toe te voegen.
2. Extensie (E): De "Aanbouwmethode". Nieuwe functies bouwen die in het systeem pluggen zonder de kern aan te raken, zoals een nieuwe kamer aan een huis toevoegen.
3. Low-code (L): De "Flowchart-methode". Visuele tools of regels gebruiken om gedrag te veranderen, zoals een bedrijfsmanager die een workflow herstructureert zonder code te schrijven.
4. Configuratie (C): De "Schakelaarmethode". Alleen instellingen of parameters wijzigen, zoals een draaiknop gebruiken om het volume aan te passen.

De onderzoekers testten dit idee op drie verschillende softwareprojecten: twee publieke projecten uit een groot tech-ecosysteem en één private gezondheidsapp. Ze ontdekten dat CLEM duidelijk het verschil kan zien tussen een systeem dat "gezond" is (voornamelijk gebruikmakend van uitbreidingen en schakelaars) en een systeem dat "ziek" is (voortdurend de eigen kern aan het hacken). Ze ontdekten echter ook iets verrassends: weten hoe een systeem verandert, voorspelt niet automatisch of het volgende maand meer bugs zal hebben. Het is een geweldige tool om de structuur van een systeem te begrijpen, maar het is geen kristallen bol voor het voorspellen van toekomstige fouten.

Het nieuwe notitieblok van de detective: Hoe CLEM werkt

Beschouw softwareontwikkeling als een drukke keuken. Jarenlang zijn chefs (ontwikkelaars) gemeten aan de hand van hoeveel gerechten ze koken (activiteitsvolume) of hoe schoon de keuken is aan het einde van de avond (statische codechecks). Maar wat als de keuken uit elkaar valt omdat ze elke keer dat ze een nieuwe speciaer nodig hebben, een muur moeten slopen om bij de voorraadkast te komen? Dat is het probleem dat CLEM oplost. Het telt niet alleen de gerechten; het observeert de methode die de chefs gebruiken om ingrediënten te verkrijgen.

Het paper stelt dat elke keer dat een softwaresysteem wordt bijgewerkt, de verandering op een van vier manieren plaatsvindt, en de mix van deze manieren alles vertelt over de gezondheid van het systeem.

• Modificatie (M) is de "Brute Kracht"-methode. Het is alsof een chef een sloophamer pakt om een muur te breken omdat hij een nieuwe plank nodig heeft. Het krijgt de klus snel geklaard, maar als je dit te vaak doet, wordt het hele gebouw onstabiel.
• Extensie (E) is de "Modulaire" methode. Het is als het bouwen van een nieuwe, losstaande kar die de keuken in rolt. De chef raakt de muren niet aan; hij voegt gewoon een nieuw hulpmiddel toe. Dit is veiliger en houdt de kernstructuur intact.
• Low-code (L) is de "Blauwdruk"-methode. Stel je een manager voor die een nieuwe flow tekent op een whiteboard die de robots vertelt wat ze moeten doen, zonder dat de robots geprogrammeerd hoeven te worden. Het is een hoger niveau van verandering.
• Configuratie (C) is de "Draaiknop"-methode. Het is gewoon het draaien aan een knop om de oven heter te maken of het licht feller te maken. Geen constructie nodig.

De auteurs betogen dat een gezond, langdurig softwaresysteem meer moet leunen op Extensie, Low-code en Configuratie, en minder op Modificatie. Als een systeem voortdurend zijn kern "Modificeert", verzamelt het waarschijnlijk "technische schuld"—een chique manier om te zeggen dat het stabiliteit leent van de toekomst en dit later met rente zal moeten terugbetalen.

Het Experiment: Drie Keukens Observeren

Om te zien of dit idee werkt, gingen de onderzoekers op een excursie naar drie verschillende "keukens" (softwarerepositories). Ze keken niet alleen naar de uiteindelijke gerechten; ze volgden de handen van de chefs gedurende maanden.

1. De "Fit" Keuken (fit-framework): Dit was een publiek project ontworpen als een plugin-systeem. Ze verwachtten dat dit vol zou zijn met "Extensies" (E).
2. De "App" Keuken (app-platform): Dit was een ander publiek project, maar het was gebouwd voor visueel low-code ontwerp. Ze verwachtten dat dit vol zou zijn met "Low-code" (L) en "Configuratie" (C).
3. De "Antisuger" Keuken: Dit was een private gezondheidsapp voor het beheren van de bloedsuikerspiegel. Het werd gebouwd door een ander team met andere tools. Ze verwachtten dat dit in een vroege, chaotische fase zat, waarschijnlijk vol met "Modificaties" (M).

De onderzoekers analyseerden 607 specifieke updates (commits) over deze projecten. Ze gebruikten een set transparante regels om naar de gewijzigde bestanden te kijken. Als een bestand in een "plugin"-map stond, telden ze het als Extensie. Als het een "flow"-bestand was, telden ze het als Low-code. Als het een kerncode-bestand was, was het Modificatie.

Wat ze vonden: De systemen zagen er verschillend uit

De resultaten waren precies zoals de "gezonde keuken"-theorie voorspelde.

• Het App-platform was inderdaad zeer "geexternaliseerd". Ongeveer 69,5% van de wijzigingen waren Extensies, met zeer weinig directe manipulatie van de kern. De "CLEM-ES"-score (een maatstaf voor hoeveel verandering werd weggehaald bij de kern) was een sterke +0,685.
• Het Fit-framework was een mix. Het had veel Extensies (33,4%), maar had ook een aanzienlijk deel Modificaties (29,1%). De score was +0,418, wat aantoonde dat het gezonder was dan een pure chaos, maar niet zo "geexternaliseerd" als het App-platform.
• De Antisuger gezondheidsapp was het tegenovergestelde. Het was bijna volledig dominant in "Modificatie", waarbij 83,0% van de wijzigingen directe kernwijzigingen waren. De score was -0,659, wat aangaf dat het zich nog in een fragiele "muren hacken"-fase bevond.

Dit bewees dat CLEM succesvol het verschil kan detecteren tussen een systeem dat groeit door vleugels toe te voegen en een systeem dat groeit door muren te slopen. De onderzoekers controleerden zelfs of hun regels eerlijk waren door twee mensen naar 160 willekeurige updates te laten kijken. Ze kwamen 100% van de tijd overeen over de hoofdcategorie, wat suggereert dat de regels solide en reproduceerbaar zijn.

De Twist: Structuur voorspelt nog geen bugs

Dit is het deel waar het paper erg voorzichtig is. Je zou kunnen denken: "Als een systeem zijn eigen muren aan het hacken is (hoge Modificatie), zou het dan niet vaker kapot gaan?" De onderzoekers testten dit. Ze keken of de CLEM-scores konden voorspellen of er de volgende maand meer "bugfixes" zouden zijn.

Het antwoord? Geen duidelijke link.
In hun data voorspelde de "Modificatie"-score niet betrouwbaar of de volgende maand vol met bugfixes zou zijn. De "CLEM-ES"-score (hoe geexternaliseerd de wijzigingen waren) had bijna geen correlatie met toekomstige bugfixes in deze specifieke steekproef.

Dit is een cruciale bevinding. De auteurs geven expliciet aan dat CLEM geen magische kristallen bol is voor het voorspellen van defecten. Het vervangt de oude manieren van het tellen van bugs of code churn niet. In plaats daarvan biedt het een ander soort inzicht. Het vertelt je iets over de structurele houding van het systeem. Een systeem met een hoge Modificatie-score heeft misschien niet meer bugs vandaag, maar het bouwt een structuur die moeilijker te onderhouden is en waarschijnlijk fragieler zal worden in de loop van de tijd. Het is als een gebouw dat structureel onveilig is; het stort misschien vandaag niet in, maar het blauwdruk is slecht.

Waarom dit ertoe doet

Het paper concludeert dat CLEM een krachtige nieuwe lens is voor softwaremanagers. Het verplaatst het gesprek van "Hoeveel code hebben we geschreven?" naar "Hoe veranderen we ons systeem?".

• Als je ziet dat een team constant Modificaties uitvoert, is dat een signaal om te pauzeren en te vragen: "Waarom breken we onze eigen muren af? Kunnen we in plaats daarvan een plugin bouwen?"
• Als je ziet dat een team voornamelijk Extensies en Configuraties uitvoert, suggereert dit dat het systeem volwassen wordt en stabieler wordt.

De auteurs zijn eerlijk over de beperkingen van hun werk. Ze geven toe dat hun steekproef klein was (slechts enkele maanden aan data van drie projecten) en dat het deel over "bugvoorspelling" niet werkte zoals gehoopt. Ze suggeren dat CLEM het beste gebruikt kan worden als een complementair instrument—een manier om toezicht te houden op de structurele gezondheid van een systeem naast traditionele metrieken. Het is geen definitief oordeel over kwaliteit, maar een zeer duidelijke, controleerbare manier om te zien of een softwaresysteem leert volwassen te worden of dat het vastzit in de gewoonte om zijn eigen fundament te slopen.

Kortom, CLEM geeft ons een vocabulaire om over de vorm van verandering te praten. Het helpt ons te zien of onze software een wolkenkrabber bouwt of gewoon bakstenen op een wankele stapel stapelt, en dat onderscheid kan het belangrijkste zijn dat we kunnen meten voor het langetermijnoverleven van elk digitaal systeem.