Iemand staat op het punt een codebase aan je over te dragen — via een overname, een investering, een leveranciers overdracht, of een nieuwe baan. Je hebt beperkte tijd, en de mensen die het hebben geschreven willen competent overkomen.
Dit is de volgorde waarin ik werk, en het is bewust niet de volgorde waarin ingenieurs natuurlijk beginnen. Niemands eerste vraag hoort over code style te gaan.
1. Kun je het bouwen?
Clone de repository op een schone machine en volg de README. Meet de tijd.
Als een nieuwe ingenieur geen werkende build krijgt in onder een uur zonder iemand te vragen, dat is je belangrijkste bevinding. Het betekent dat onboarding weken kost, dat kennis in mensen leeft in plaats van in de repo, en dat elk estimate dat je krijgt optimistisch is. Alles anders op deze lijst is minder belangrijk dan dit.
2. Kun je het releasen?
Vraag of je een deploy mag zien. Niet een beschrijving ervan — een echte deploy, live.
- Hoeveel tijd van merge tot production?
- Hoeveel mensen moeten iets doen?
- Wat is de rollback, en is die ooit gebruikt?
- Wie beheert de signing keys en store credentials? Dit heeft meer acquisities gedood dan slechte code.
Een team dat niet op vraag kan releasen kan ook niet op vraag dingen fixen. Dat is geen code-quality probleem; het is een business-continuity probleem.
3. Waar lekt het geld weg?
Zet de infrastructure bill naast het user count. Afwijkingen hier zijn de goedkoopste winsten die je zult vinden, en ze zeggen je hoe zorgvuldig dit is gebouwd.
4. Wat gebeurt er als het breekt?
Vraag om de laatste drie incidents. Niet een status page — het echte verhaal. Als er geen antwoord is, wordt er niets gemonitord of niets opgeschreven, en beide leiden tot hetzelfde: je zult verrast zijn, en je weet niet waarom.
Controleer op crash reporting en error tracking, en of iemand ernaar kijkt. Een app die draait op 96% crash-free met niemand die het weet, vertelt je precies hoe het team werkt.
Een twee-dagenschema dat werkt
Als je echt twee dagen hebt, besteed ze zo in plaats van code van uur één te lezen:
- Ochtend één — bouwen en releasen. Clone, build, watch a deploy. Twee bevindingen voor de lunch, en dat zijn meestal de twee die ertoe doen.
- Middag één — praten met de ingenieurs. Individueel, niet als groep. Vraag wat ze zouden fixen als ze een vrije maand hadden. De consistentie van de antwoorden zegt je net zoveel als de antwoorden zelf.
- Ochtend twee — sample de code. Auth, payments, het grootste file, de test suite, de dependency list. Beperkt tot drie uur.
- Middag twee — access en ownership. Accounts, keys, licences, contracts, data. Het saaie gedeelte, en het gedeelte dat deals blokkeert.
Merk op dat code sampling een kwart ervan is. Die verhouding verbaast ingenieurs en stelt iedereen anders gerust, en het is correct.
Vragen die eerlijke antwoorden opleveren
Hoe je vraagt bepaalt wat je leert. Deze werken:
- "Wat zou je fixen als je een vrije maand had?" Mensen houden van dit antwoord en het oppervlakt de echte schuld in negentig seconden. "Niets" is zelf een antwoord, en niet een goed.
- "Wat is het deel waar je een nieuwe hire voor zou waarschuwen?" Elke codebase heeft er één. Erover verteld worden zonder aanleiding is een goed teken over het team.
- "Wanneer ging iets voor het laatst fout in production, en wat gebeurde er?" Test of ze incidents hebben en of ze ervan leren.
- "Wat zou breken als traffic 10× hoger zou gaan?" Een goed team antwoordt meteen met een specifieke component. Vaagheid betekent dat niemand erover nagedacht heeft.
Vermijd "is de code goed?" Je krijgt een defensief antwoord dat je niets vertelt, en je hebt de goodwill verspild die je nodig had voor de nuttige vragen.
5. Kijk nu naar de code — maar alleen naar deze
Je kunt een codebase niet in twee dagen lezen, dus probeer het niet. Sample bewust:
- The authentication and payment paths. Waar security bugs en juridische exposure leven. Lees deze goed.
- Het grootste file in de repo. Elke codebase heeft één monster. De grootte zegt je hoe lang het team onder druk staat zonder schuld af te betalen.
- De test suite — draait die, en vertrouwt iemand erop? Coverage percentage is bijna nutteloos. "Draai je tests voor releasen, en vangen ze ooit iets?" is de echte vraag.
- Dependency age. Een dependency drie major versies achter is een project dat niemand heeft gepland.
- Commit history. Wie heeft dit eigenlijk geschreven? Als 80% van commits van één persoon komt die vertrekt, koop je geen codebase — je koopt een herschrijving.
6. De juridische laag die iedereen vergeet
- Licence audit. Een copyleft licentie in een commercieel product is een echt probleem, altijd te laat ontdekt.
- Bezitten ze de code? Contractor agreements zonder IP assignment zijn normaal en duur.
- Waar is persoonlijke data, en wie kan eraan? Onder de AVG wordt dit jouw probleem zodra je ondertekent.
- Third-party accounts. Store listings, domeinen, cloud accounts, analytics. Alles geregistreerd op een persoonlijk email is een gijzelaarssituatie in wording.
Bevindingen die de prijs moeten veranderen
Het meeste wat een audit opleverde is normaal — elke echte codebase draagt schuld. Dit zijn degenen die echt materieel zijn:
- Niemand die nu werkt kan het deployen.
- Signing keys, store accounts of domeinen worden niet door het bedrijf beheerd.
- De IP chain is gebroken.
- Één vertrekkend persoon schreef het meeste ervan.
- Een dependency of platform requirement dwingt een rewrite binnen twaalf maanden.
Alleen één daarvan gaat over code. Technical due diligence gaat vooral niet over techniek — het gaat erom of de kennis, access en eigendom echt met de deal meegaan.
Wat goed eruit ziet
Je weet het binnen een uur. Goede teams geven je een repository dat bouwt, een document dat uitlegt waarom dingen zo zijn, en een ingenieur die de zwakke punten vrijwillig vertelt voordat je ze vindt. Die laatste is het sterkste signaal dat is: mensen die je vertellen waar de lijken begraven zijn, zijn mensen die nagedacht hebben over de lijken.
Als je dit zelf liever niet doet, is het precies wat een product audit is voor — een vaste hoeveelheid uren, een buitenstaander opinie, en geen prikkel om beleefd te zijn over het antwoord.