Zo beoordeel je een voorstel voor drie maanden refactoren

Je tech team legt een voorstel neer: drie maanden werk aan een grote refactoring. De business stelt daarop de enige vraag die telt in haar taal, namelijk wat het oplevert. Het team antwoordt met technical debt en maintainability. Daarna staat het gesprek stil, en meestal wint degene die het hardst kan doorzetten in plaats van degene die gelijk heeft.

Dat is geen technisch probleem. Het is een vertaalprobleem, en daaronder zit een vertrouwensprobleem. De business kan de claim niet toetsen, dus valt ze terug op wantrouwen. Het team voelt zich niet geloofd, dus valt het terug op jargon. Beide partijen graven zich in.

Ik haal die discussie uit de loopgraven door hem te verplaatsen. Niet naar techniek, maar naar risico. Risico is een taal die een directie al spreekt, en het is de enige taal waarin een refactoring en een marketingcampagne op dezelfde meetlat passen.

Vertraging

De eerste vraag is hoeveel langzamer je levert door de code zoals hij nu is. Niet in gevoel, maar in doorlooptijd. Neem de laatste tien features die je hebt opgeleverd, en splits ze in werk dat het oude deel van de codebase raakt en werk dat eromheen loopt. Vergelijk de doorlooptijd van beide groepen.

Zit daar een verschil van dertig procent, dan heb je geen mening meer maar een getal. Op een team van zes ontwikkelaars is dertig procent bijna twee fte die je kwijt bent aan de vorm van je code. Dan is drie maanden herstelwerk geen kostenpost, maar een investering met een terugverdientijd die je kunt uitrekenen.

Blijkt het verschil klein, dan heb je ook wat: het argument houdt geen stand en het voorstel gaat terug. Dat is de winst van meten. Je krijgt niet altijd gelijk, maar je krijgt wel een besluit dat je een jaar later nog kunt uitleggen.

Veiligheid

De tweede vraag draait het perspectief om. Niet wat de refactoring oplevert, maar wat het kost om hem niet te doen. Draai je op componenten die geen onderhoud meer krijgen, dan groeit dat risico vanzelf door, ook in de maanden dat niemand eraan werkt.

Dit is het deel dat het makkelijkst hard te maken is, want je hoeft niets te schatten. Een afhankelijkheidsscan geeft je vandaag een lijst met bekende kwetsbaarheden en hun ernst. Zet die lijst naast de meldplicht die voor jouw organisatie geldt, en de vraag verandert van technisch naar bestuurlijk. Een directie die de uitkomst van een datalek moet uitleggen aan klanten en toezichthouder, weegt drie maanden werk anders.

Let op de valkuil: dit argument is zo sterk dat het verleidt tot overdrijven. Doe dat niet. Eén keer een risico opblazen dat niet uitkomt, en je bent je geloofwaardigheid kwijt voor de volgende drie voorstellen.

Verloop

De derde vraag stelt bijna niemand, en die is vaak het duurst. Wat doet deze code met de mensen die er dagelijks in werken. Ontwikkelaars die hun weken vullen met storingen en workarounds, vertrekken. Niet luidruchtig, en zelden met de echte reden in het exitgesprek.

Reken die kosten een keer door voor je eigen organisatie: werving, inwerktijd tot iemand zelfstandig levert, en de kennis die met de vertrekker mee naar buiten loopt. Bij senior technische rollen loopt dat bedrag hoog op, en anders dan de andere twee V's komt het in één klap.

Vraag het aan je team voordat je het uitrekent. De mensen die het weten, zitten al in het gebouw.

Wat het gesprek verandert

Met deze drie vragen gaat het voorstel niet meer over code. Het gaat over snelheid, over risico en over het vasthouden van je mensen. Dat zijn drie onderwerpen waar een directie wel een besluit over kan nemen, en waarover ze zich achteraf kan verantwoorden.

Belangrijker is wat het doet met de verhouding. Een team dat zijn voorstel zo onderbouwt, vraagt niet om vertrouwen op basis van expertise alleen. Het legt zijn redenering open, inclusief de plek waar de cijfers tegenvallen. Dat is precies de reden waarom het de volgende keer wel wordt geloofd.

Van de drie is verloop meestal het lastigst te kwantificeren, omdat de kosten verspreid vallen en de oorzaak zelden wordt opgeschreven. Wie daar een werkbare methode voor heeft gevonden, hoor ik graag.