Microsoft lanserte Windows Vista i 2007, med varierende grad av suksess.
Forskningsavdelingen i Microsoft gikk til verks for å finne ut hva som gikk galt.
De lærte noe overraskende (eller kanskje ikke?) om hva den største kilden til bugs er.
Microsoft Research, og Vista
Windows Vista var en problematisk release. Mange plasserer Vista sammen med Windows Millennium Edition (ME), som sammen utgjør de to Windows-versjonene som rett og slett var ganske dårlige.
Vi skal ikke gå i dybden på hva det var Vista sleit med. Men de sleit, og Microsoft visste det. De hadde for eksempel denne reklamekampanjen i 2008: The Mojave Experiment, hvor Microsoft gjør en slags practical joke for å folk til å si positive ting om Vista:
Microsoft bestemte seg for at de skulle grave ordentlig i hva som gikk galt med Vista.
Forskningsavdelingen til Microsoft, Microsoft Research, ble dermed satt på oppgaven om å utvikle metoder og fremgangsmåter Microsoft kunne bruke i fremtidige prosjekter for å unngå at slike ting skulle skje igjen.
Nei, de fleste norske utviklere bruker ikke Mac
Men langt flere norske utviklere bruker Mac enn Linux. 🐧
Hva fant de ut?
Microsoft Research utviklet en ny statistisk modell for å forutsi om en modul kommer til å føre til bugs eller ikke. For å vurdere kvaliteten til den nye modellen de laget, sammenliknet de den med andre mere eller mindre tradisjonelle modeller:
- Code Churn. Måler antall endringer i versjonskontroll per modul.
- Code Complexity. Måler antallet code paths, antall funksjoner som kaller hverandre internt i modulen, dybde på arv-hierarkier, kobling mellom objekter, antall subklasser, mm.
- Dependencies. Måler antall eksterne moduler som kaller på deg, hvor mange eksterne moduler du kaller på, hvor mange lag en modul er fra hardwaren, mm.
- Code Coverage. Tradisjonell test-dekning som mange utviklere kjenner til fra før
- Pre-Release Bugs. Antall bugs i issue-trackeren før release av modulen.
- Jeg tror Microsoft glemte utviklerne
Den norske Azure-direktøren om norske datasentre, VSCode, GitHub, Windows og ikke minst; Linux.
I tillegg til disse eksisterende modellene, lagde Microsoft en ny modell:
- Organizational Complexity. Denne måler antall utviklere som har jobbet på modulen, antall eks-utviklere som tidligere var en del av teamet som jobbet med modulen, hvor stor andel av organisasjonen som berører en modul, avstand fra utviklere på modulen til beslutningstager, mm.
Microsoft har publisert et studie, hvor de brukte statistikk for å måle disse ulike modellene opp mot hverandre.
Hvis du lurer på mer detaljer om statistikken, kan du høre på podcast-episoden denne artikkelen er basert på. Men kort fortalt, viser de to kolonnene i tabellen nedenfor følgende:
- “Precision” - hvor mange moduler som hadde bugs, klarte vi å oppdage?
- “Recall” - av de du trodde hadde bugs, hvor mange hadde faktisk bugs?
Resultatene under kommer fra at Microsoft kjørte modellene sine på modulen i seg selv, og sammenliknet med hvor mange bugs modulen faktisk hadde 6 måneder etter release. Da det var gjort, fant de følgende:
| Metodikk | Precision | Recall |
| Organizational Structure | 86.2% | 84.0% |
| Code Churn | 78.6% | 79.9% |
| Code Complexity | 79.3% | 66.0% |
| Dependencies | 74.4% | 69.9% |
| Code Coverage | 83.8% | 54.4% |
| Pre-Release Bugs | 73.8% | 62.9% |
Organisasjonsstrukturen hadde klart høyest precision - så den fikk med seg mange bugs. Og den har klart høyest recall - så av de modulene den trodde hadde bugs, hadde nesten alle faktisk bugs i virkeligheten også.
Ingen over og ingen ved siden! Avstand til beslutningstagere, og antall utviklere, er utvilsomt den målestokken som fører til flest bugs i koden din.
Noe som sjokkerer meg, er at den eneste metoden jeg faktisk har brukt selv - code coverage - er den dårligste.
Utrolig, men sant!
«Den eneste metoden jeg faktisk har brukt selv, code coverage, er den dårligste.»
Og studiet er replikert!
Å replikere studier er kjempeviktig. Vitenskapen sliter med The Replication Crisis, hvor fundamentale og høyt siterte studier ikke har latt seg replikere.
Heldigvis er verdien av organisasjonskompleksitet til å forutsi software-bugs blitt replikert!
I det replikerte studiet er ikke organisasjonsstrukturen like kraftig. Den er nest kraftigst på “precision”, men har den nest lavest på “recall”. Dette studiet konkluderer likevel med at organisasjons-elementer er verdt å studere videre. Studiet baserer seg også på funksjoner i C/C++, og ikke hele moduler slik Microsoft Research gjorde, som kan forklare litt av forskjellene.
En annen grunn til forskjellene kan være at Microsoft faktisk ikke klarte å måle alt. Microsoft er jo en av verdens største software-organisasjoner, så det gir mening av Microsoft er ett av stedene hvor organisasjonskompleksitet slår aller kraftigst ut.
Vi må også tenke på forskjellen mellom formell organisasjonskultur, og den mere informelle kommunikasjonsstrukturen i en organisasjon. Se Ed Catmull, sjefen i Pixar, snakke om akkurat dette (10:06):
.
Slik hører du kode24-timen, hver fredag
Vi guider deg til hvordan du finner din nye favoritt-podcast for norske utviklere.