Was technische Due Diligence findet
Zwei Wochen fremden Code lesen, bevor man eine Neuentwicklung anbietet. Die Befunde betreffen selten Codequalität und fast immer Kopplung.
Wir bepreisen keine Neuentwicklung, die wir nicht gelesen haben. Zwei Wochen technische Due Diligence kommen zuerst, und der Kunde bekommt den Bericht, ob er mit uns weitermacht oder nicht. Das hat uns gelegentlich Aufträge gekostet — genau darum machen wir es so.
Der Befund, der einen Plan ändert, ist fast nie Codequalität. Hässlicher Code lässt sich billig ertragen. Es zählt die Kopplung: wie viel bricht, wenn man eines ändert, und ob irgendjemand vorher sagen kann, was.
Das Zweite, wonach wir suchen, ist der tatsächliche Ort der Geschäftslogik. Häufig liegt sie nicht in der Anwendung. Wir haben Preisregeln in Tabellenformeln gefunden, in einem Datenbank-Trigger und einmal in einem geplanten Job, dessen Autor drei Jahre zuvor gegangen war. Was niemand formulieren kann, lässt sich nicht neu bauen.
Dann die betriebliche Wirklichkeit. Können Sie das System von Grund auf hochziehen? Gibt es einen Test, der fehlschlägt, wenn etwas kaputt ist? Was passiert um drei Uhr nachts, wenn der Sync-Job stirbt — gibt es eine Warnung, und ist jemand dafür zuständig? Systeme, die sich nicht aus dem Quellcode neu aufbauen lassen, sind weit häufiger, als man zugibt.
Der Bericht, den wir schreiben, ist bewusst langweilig: was existiert, was riskant ist, und was es kosten würde, es zu reparieren statt zu ersetzen, jeweils mit Aufwandsspannen. Manchmal lautet die ehrliche Empfehlung, gar nicht neu zu bauen und stattdessen einen Bruchteil des Budgets in Tests und Beobachtbarkeit zu stecken.