VQD-CTS Prediction Model: An AI-Driven Framework for Predicting Cost-to-Serve Using Engineering Velocity, Quality, and Developer Experience

Stel je voor dat je een enorme, drukke pizzeria runt. Je hebt een team van chefs (de ontwikkelaars), een luxe oven (de technologie) en een constante stroom aan bestellingen (de softwarefuncties). In de oude dagen, als je wilde weten hoeveel het zou kosten om een pizza te maken, gokte je gewoon op basis van hoeveel pizza's je vorige week hebt gemaakt. Maar dat is een beetje alsof je het weer probeert te voorspellen door naar de kalender van gisteren te kijken; het mist de onweersbuien, de wind en het feit dat je oven misschien kapot is.

In de wereld van software worden bedrijven geconfronteerd met een soortgelijke puzzel. Ze houden bij hoe snel hun teams werken (Velocity), hoeveel fouten ze maken (Quality) en hoe tevreden hun chefs zijn met hun gereedschap en omgeving (Developer Experience). Maar voor een lange tijd kon niemand precies uitrekenen hoe deze drie dingen samenkwamen in de uiteindelijke rekening — de "Cost-to-Serve". Het is alsof je weet dat je veel kaas hebt gebruikt en een blije chef hebt, maar niet weet of die pizza je $10 of $100 kost om te maken. Dit artikel probeert dat mysterie op te lossen door een superintelligent computerbrein (een AI) te bouwen dat al die rommelige details kan bekijken en de prijs kan voorspellen voordat de pizza zelfs maar gebakken is.

Het VQD-CTS Voorspellingsmodel: Een Kristallen Bol voor Softwarekosten

De onderzoekers, Basavaraj Chunchure en Mantesh Patil, hebben een nieuwe tool gebouwd genaamd het VQD-CTS Voorspellingsmodel. Denk bij "VQD" aan een geheime saus gemaakt van drie ingrediënten: Velocity (hoe snel het team beweegt), Quality (hoeveel bugs ze vangen) en Developer Experience (hoe makkelijk het voor hen is om hun werk te doen). "CTS" staat voor Cost-to-Serve, wat de totale rekening is voor het leveren van een stuk software aan een klant, inclusief alles van de elektriciteit voor de servers tot de salarissen van de mensen die de bugs oplossen.

Het team heeft niet zomaar gegokt; ze hebben hun AI gevoed met een enorme berg nep-maar-realistische data — 10.000 records van verschillende softwareprojecten — om het te leren hoe deze drie ingrediënten mengen om een kostprijs te creëren. Het is alsof je een robotchef traint door hem 10.000 verschillende scenario's van het maken van pizza's te laten bekijken, van de scenario's die soepel verliepen tot de scenario's waarbij de oven in brand vloog.

Wat Hebben Ze Ontdekt?

De robotchef bleek verrassend goed in zijn werk te zijn. Toen ze hem testten op nieuwe, ongeziene data, kreeg hij een score van 0,885 (op een schaal waarbij 1,0 perfect is). In gewone mensentaal betekent dit dat het model bijna 90% van de redenen verklaart waarom kosten omhoog of omlaag gaan. Gemiddeld lag de voorspelling van de prijs slechts 79,93 eenheden valuta af (het paper gebruikt een generieke eenheid, dus denk aan "punten" op een scorebord).

Maar de echte magie zat niet alleen in de score; het was in wat de AI hen vertelde over waarom kosten ontstaan. De onderzoekers vroegen het model: "Wat is de grootste reden dat onze pizzarekening zo hoog is?" en het model wees met een digitale vinger naar vier hoofdverdachten:

1. Code Complexiteit: Dit was de grootste schurk. Als de code rommelig en moeilijk te begrijpen is, schieten de kosten omhoog. Het is alsof je een huis probeert te bouwen met overal verstrengelde draden; het duurt eeuwen om het te repareren, en elke keer als je er iets aan aanraakt, gaat er ergens anders iets kapot.
2. Defect Dichtheid: Dit is gewoon een chique manier om te zeggen: "hoeveel bugs er in de code verstopt zitten." Hoe meer bugs, hoe duurder het project wordt vanwege alle herstelwerkzaamheden en klantklachten.
3. Cycle Time: Dit is de tijd die het kost om van "Ik heb een idee" naar "Het werkt op je telefoon" te gaan. Als deze tijd sleept, gaan de kosten omhoog vanwege coördinatieproblemen en gemiste kansen.
4. Infrastructure Cost Share: Dit is de rekening voor de cloudservers en tools. Naarmate bedrijven meer van hun werk naar de cloud verplaatsen, wordt dit deel van de rekening een enorm deel van de totale kosten.

De Verrassende Waarheden

Het model onthulde ook zaken die misschien een beetje tegenintuïtief aanvoelen. Lange tijd dachten veel bazen dat als je je team maar sneller liet werken (hogere Velocity), de kosten zouden dalen. De AI zegt: "Ho stop!" De studie vond dat pure snelheid er niet veel toe doet als de code rommelig is of het team ongelukkig is. Sterker nog, het pushen voor snelheid zonder aandacht te besteden aan kwaliteit of de ervaring van de ontwikkelaars, kan de rekening op de lange termijn juist hoger maken vanwege alle fouten die je later moet herstellen.

Een andere verrassing was dat de grootte van het team niet zo belangrijk was als mensen dachten. Een groot team is niet automatisch duur als ze georganiseerd en ervaren zijn; een klein team kan duur zijn als ze verdwaald en in de war zijn. Het gaat niet om het aantal chefs; het gaat erom hoe goed ze het recept kennen en hoe scherp hun messen zijn.

Hoe Zeker Zijn Ze?

De onderzoekers zijn vrij zelfverzekerd over deze resultaten, maar met een paar kanttekeningen. Ze hebben hun model gebouwd met behulp van een enorme dataset van synthetische (door de computer gegenereerde) data die echte projecten nabootst. Ze hebben het getest over verschillende soorten projecten, zoals het bouwen van nieuwe systemen vanaf nul (Greenfield) of het repareren van oude systemen (Brownfield), en het werkte in bijna alle gevallen goed.

Ze geven echter toe dat dit een simulatie is. Ze hebben nog niet een echt bedrijf een heel jaar lang hun model zien gebruiken om te zien of het hen miljoenen dollars in de echte wereld bespaart. Ze merkten ook op dat het model het beste werkt wanneer een bedrijf in de basis goede data heeft. Als een bedrijf blind vliegt en niet bijhoudt hoeveel bugs ze hebben of hoe lang taken duren, kan het model zijn magie niet uitoefenen.

De Kernboodschap

Het VQD-CTS model is als een GPS voor softwaremanagers. In plaats van blind te rijden en te hopen dat ze niet zonder benzine (geld) komen te zitten, kunnen ze nu naar hun snelheid, de staat van hun auto en de stemming van hun chauffeur kijken om precies te voorspellen wat de rit hen zal kosten. Het suggereert dat als je geld wilt besparen, je niet alleen je team de opdracht moet geven om "sneller te gaan". In plaats daarvan moet je de rommelige code opruimen, de bugs vroegtijdig oplossen en ervoor zorgen dat je ontwikkelaars de tools hebben die ze nodig hebben om gelukkig te zijn. Dat, zo suggereert het paper, is het echte recept voor een goedkopere, betere pizza.