Din kodebase er en kunnskapsmine – men hvem graver?
Her er noe som bør få enhver CTO og lead developer til å føle seg ukomfortabel: den mest sofistikerte forståelsen av bedriften din lever kanskje ingen andre steder enn i produksjonskoden.
En fersk forskningsartikkel fra ServiceMatch-teamet utforsker en provoserende idé. De argumenterer for at modne programvaresystemer ikke bare er verktøy som kjører virksomheten din — de er kjørbare representasjoner av alt organisasjonen har lært om den virksomheten. Det som er problemet? Den kunnskapen har gjemt seg i fullt dagslys, låst inne i repositories som bare ble lest av kompilatorer og (av og til) mennesker.
Dokumentasjonsmyten
Vi har alle vært der. En ny ingeniør kommer inn på teamet og får servert en diger bunke med Confluence-sider, arkitekturbeslutninger og Wiki-oppføringer. "Dette skal få deg opp til speed," sier noen med optimistisk sikkerhet.
Det vil det ikke.
Dokumentasjon fanger opp det noen syntes var verdt å skrive ned, på et tidspunkt som kanskje var år siden. Den misser edge cases. Den misser diskusjonene som skjedde i møter som formet beslutninger. Den misser forretningslogikken som utviklet seg gjennom tusenvis av commits, hver eneste en som kjempet med et virkelig scenarie.
Ifølge Peter Naur sin argument fra 1985 (ja, samme Naur som ga oss Backus-Naur form), kan programdokumentasjon aldri fullt ut fange "teorien" bak et system. Den virkelige forståelsen lever i folks hoder. Når de menneskene forlater selskapet, forlater teorien med dem.
Men her blir det interessant.
AI endrer leserproblemet
Naur sitt argument handlet om to typer lesere: kompilatorer (som kjører kode uten å forstå den) og mennesker (som forstår den sakte og dyrt). Umuligheten av dokumentasjonsgjenoppretting forutsatte at ingen annen type leser eksisterte.
Store språkmodeller er en tredje type leser. Og de er overraskende gode til å rekonstruere de implisitte teoriene innebygd i kode.
ServiceMatch-systemet gir overbevisende bevis. Deres CMDB-plattform koder bedriftskonfigurasjonskunnskap som ville fylt bind hvis det var skrevet som prosa. Men her er greia — det er allerede skrevet, bare ikke i prosa. Det er i kode.
Tenk på identitetsoppløsningslogikken deres. I stedet for en konsulents essay om "hvordan enhetsidentitet fungerer," har de en konfigurasjonsfil med vekter: serienummer (25), vertsnavn (25), aktivabevis (25), IP-adresse (20), MAC-adresse (15). Pluss konfidensgrenser og konfliktløsningsregler. Hvert eneste tall representerer en diskusjon noen vant. Hver konflikttype representerer en virkelig hendelse som skjedde et sted.
Dette er ikke en beskrivelse av policyen. Dette ER policyen, som kjører nattlig mot faktiske bedriftsmiljøer.
Hva dette betyr for teamet ditt
For utviklere og tekniske ledere har denne forskningen praktiske implikasjoner:
Koden din er dokumentasjon du ikke har vedlikeholdt — og det har sine egne fordeler. I motsetning til utdaterte wiki-sider blir kode som kjører i produksjon konstant validert. Hvis dokumentasjonen er uenig med koden, er dokumentasjonen feil.
AI-verktøy blir bedre på å trekke ut denne kunnskapen. Vi beveger oss mot en verden der det å spørre en AI om "hvordan vi håndterer enhetsidentitetskonflikter" kunne gi tilbake ikke bare dokumentasjon, men den faktiske resonnementet kodet i vektene og grensene.
Den virkelige kunnskapen lever i edge cases. Hovedflytene er vanligvis godt dokumentert. Det er spesialhåndteringen, unntakene, hjørnetilfellene løst over år som inneholder den dype institusjonelle kunnskapen.
Varselstegnet
Det er en ubehagelig korollar til alt dette: hvis forretningslogikken din bare er i koden din, og koden din har dårlig testdekning, uklare navn eller kaotisk struktur, sitter du på en haug med kunnskap som er nesten umulig å trekke ut.
ServiceMatch-teamet fant at påstanden deres — at "repositoryet er tilstrekkelig" — bryter sammen på forutsigbare måter. Naur sitt tause residuum er ekte. Noe kunnskap lever virkelig bare i folks hoder.
Men det sterkere funnet er at mer overlever i kode enn vi trodde var mulig. Repositoryet fanger opp langt mer teori enn dokumentasjon noen gang kunne — vi trengte bare en ny type leser for å trekke det ut.
Hva du skal gjøre med dette
Hvis du er en startup eller voksende teknologiselskap, her er et rammeverk for å tenke på dette:
- Stol mer på koden din enn dokumentene dine når de to er uenige
- Skriv kode som dokumenterer resonnementet sitt — meningsfulle variabelnavn, klare funksjoner, kommentarer som forklarer HVORFOR, ikke bare HVA
- Behandle konfigurasjon som institusjonell kunnskap — de vektene og grensene er beslutninger verdt å bevare
- Begynn å utforske AI-verktøy som kan granske kodebasen din som en kunnskapskilde
Koden du skriver i dag er morgendagens institusjonelle kunnskap. Få den til å telle.