Wat technische due diligence oplevert
Twee weken andermans codebase lezen voordat u een herbouw offreert. De bevindingen gaan zelden over codekwaliteit en vrijwel altijd over koppeling.
Wij offreren geen herbouw die we niet hebben gelezen. Twee weken technische due diligence komen eerst, en de klant krijgt het rapport of hij met ons doorgaat of niet. Dat heeft ons af en toe werk gekost, en dat is precies waarom we het zo doen.
De bevinding die een plan verandert is vrijwel nooit codekwaliteit. Lelijke code is goedkoop om mee te leven. Wat telt is koppeling: hoeveel breekt er als u één ding wijzigt, en kan iemand u vooraf vertellen wat.
Het tweede waar we naar zoeken is waar de bedrijfslogica werkelijk woont. Vaak niet in de applicatie. Wij hebben prijsregels aangetroffen in spreadsheetformules, in een databasetrigger en ooit in een geplande taak waarvan de auteur drie jaar eerder was vertrokken. Wat niemand kan formuleren, kunt u niet herbouwen.
Dan de operationele werkelijkheid. Kunt u het systeem vanaf nul opbouwen? Is er een test die faalt als er iets stuk is? Wat gebeurt er om drie uur 's nachts als de synctaak sterft — komt er een melding, en is er een eigenaar? Systemen die niet vanuit de broncode te herbouwen zijn, komen veel vaker voor dan men toegeeft.
Het rapport dat wij schrijven is bewust saai: wat er is, wat riskant is, en wat het zou kosten om het te repareren versus vervangen, met inspanningsbandbreedtes erbij. Soms is de eerlijke aanbeveling om helemaal niet te herbouwen en in plaats daarvan een fractie van het budget aan tests en observability te besteden.