Meiden Sie Fallstricke in einer Software Due Diligence

Die Rolle von Software-Assets in M&A-Transaktionen wird immer wichtiger für die Bewertung von Geschäftsrisiken und des kommerziellen oder strategischen Werts des Targets. Der enge Zeitrahmen macht es offensichtlich unumgänglich, einen tool-gestützten Ansatz für die Bewertung des Technologiestatus und der inhärenten Risiken anzuwenden. Es setzt sich zunehmend die Erkenntnis durch, dass die weit verbreiteten statischen Code-Analyse-Tools im Vergleich zur Analyse der Historie des Codes und seiner Änderungen nicht die notwendige Tiefe an Einsichten für den Investor liefern können. 

In diesem Blog erläutern wir, warum die Identifizierung von relevantem Code und potenziell risikobehafteten Hotspots, die einer Verbesserung bedürfen, mehr als nur Codequalität und hohe Code-Änderungsraten berücksichtigen muss. Im Beitrag Software Due Diligence – Entwickler und ihre Zusammenarbeit im Fokus konzentrieren wir uns auf den menschlichen Faktor und gehen darauf ein, warum die Identifizierung der Key-Entwickler über Wissensinseln hinausgehen muss. 

Einführung

Erst kürzlich haben einige Publikationen einen tool-basierten Ansatz vorgestellt und einige wertvolle Erkenntnisse geliefert:

1. Code ist nur an relevanten Stellen verbesserungswürdig. Es ist weder möglich (aufgrund von Budget- und Kapazitätsbeschränkungen), noch notwendig, die “Qualität” über die gesamte Codebasis zu verbessern.
2. Softwaresysteme sind oft zu kompliziert, um die Analyse nur auf den letzten Code-Snapshot zu stützen und daraus verlässliche Schlüsse abzuleiten.  
3. Der menschliche Faktor der Software-Entwicklung, wie die Identifizierung von Key Entwicklern, muss Teil der tool-basierten Risikoanalyse und möglicher Konzepte zur Risikominderung sein. Es scheint großartig zu sein, ein paar Star Entwickler zu haben, aber wenn sie zu Wissensinseln werden, d.h. zu Mitwirkenden, die ausschließlich alleine Teile des Codes erstellen und pflegen, können sie leicht zu einem ernsthaften Risiko werden, anstatt ein Aktivposten zu sein.
4. Die Software Due Diligence muss auf Informationen basieren, die aus der Code-Basis selbst und den historischen Daten aus den verwendeten Entwicklungswerkzeugen wie einem Code-Repository abgeleitet werden, statt nur auf Funktionsprüfungen, Code-Reviews und ein paar Interviews.

Allerdings birgt auch die Analyse historischer Daten des Codes einige Fallstricke und führt potenziell zu einfachen Fehlern, denen man sich beim Ziehen von Schlussfolgerungen bewusst sein muss. Wir werden eine Reihe von Blogartikeln über kritische Aspekte bei der Durchführung einer tool-basierten Software Due Diligence veröffentlichen. 

Wir werden darlegen, wie wir bei Cape of Good Code diese Fallstricke vermeiden, indem wir unsere proprietäre DETANGLE-Analyse-Suite als Teil unserer Software-Due-Diligence-Methodik einsetzen.

Hotspots — Von KPIs zur Code- UND Architekturqualität

Auf den ersten Blick sehen Code-Bereiche, die sich häufig ändern, wie gute Kandidaten aus, die mit Priorität analysiert werden sollten. Die Analyse der Änderungshistorie (manchmal auch “verhaltensbasierte Codeanalyse” genannt) und die Untersuchung der Codequalität von sich häufig änderndem Code scheint also der richtige Ansatz anstelle der statischen Codeanalyse zu sein. Aber klingt das nicht wie ein Henne-Ei-Problem: verursacht schlechte Codequalität die hohen Änderungsraten oder führen alle Änderungen zu schlechter Codequalität? Es ist schwer, den Unterschied festzustellen. Außerdem stellt sich die Frage, ob viele Änderungen durch die Entwicklung neuer Funktionen oder durch Wartungsarbeiten wie Bugfixing entstehen? 

Was ist also eine bessere Vorgehensweise? Die Messung des Wartungsaufwands von Code-Bereichen würde es ermöglichen, die potenziellen Auswirkungen schlechter Code-Qualität aufzudecken.  Im Allgemeinen schlagen wir vor, geschäftsrelevante KPIs als Ausgangspunkt zu verwenden, um riskante Hotspots des Codes zu identifizieren und eine genauere Ursachenanalyse durchzuführen. 

Ein wichtiger KPI ist die Maintenance Effort Ratio. Es zeigt den Anteil des Wartungsaufwands im Verhältnis zum gesamten Entwicklungsaufwand. Es misst den Wartungsaufwand, indem geänderte Codezeilen über das Code-Repository intelligent gewichtet und aggregiert und sie mit Fehlern in Verbindung bringt, die von Issue-Trackern erfasst wurden.

Die Maintenance Effort Ratio wird kritisch (und damit ein Risiko), wenn sie einen bestimmten Schwellenwert zwischen 20 und 40% überschreitet, da diese Entwicklungskapazität sicherlich nicht für die wertschöpfende Entwicklung neuer Features verwendet wird. Dies kann auf ausgewählte Code-Bereiche heruntergebrochen werden.

Für die weitere Untersuchung von Code-Qualitätsmetriken (wie die kognitive Komplexität, Code-Duplikationen und potenzielle Bugs) können statische Code-Analyse-Tools in unsere DETANGLE-Plattform integriert werden, um auch diese Metriken zu nutzen.  Als erste Schlussfolgerung können anschließend alle Bereiche mit schlechter Codequalität ABER geringem Wartungsaufwand ignoriert werden. 

Hinzu kommt, dass in der Realität bei weitem nicht alle Wartungs-Hotspots mit schlechter Codequalität zusammenhängen. Hier ist eine weitere Analyse erforderlich. Unserer Erfahrung nach ist die Architekturqualität viel wichtiger als die Codequalität, wenn wir über qualitativ hochwertige Software mit einem langen nützlichen Lebenszyklus sprechen. Unsere DETANGLE Architektur-Qualitätsmetriken der Feature-Kopplung und Kohäsion korrelieren häufig mit dem Auftreten von hohem Wartungsaufwand. 

Bild 1: Lokale und globale Kopplung von Produktfeatures

Die Abbildung visualisiert die Feature-Kopplung der deutschen Corona-Warn-App über den Code. Die benannten Bögen stellen Features der Risikoberechnung dar, die mit Version 1.9 eingeführt wurden. Diese sind untereinander lokal gekoppelt, wie ihre Verbindungen zeigen. Außerdem zeigen diese Features auch eine hohe globale Kopplung zu allen nicht verwandten Features.

Feature Effort Effectiveness

Deshalb haben wir einen weiteren KPI eingeführt, der die Leichtigkeit des Hinzufügens neuer Funktionen erfasst. Wir nennen das KPI den Feature Effort Effectiveness Index. Die Architektur-Qualitätsmetriken der Feature-Kopplung und Kohäsion zeigen mit hoher Genauigkeit, dass eine schlechte Architektur zu einer geringeren Feature Effort Effectiveness führt, was bedeutet, dass das Hinzufügen neuer Features mehr Kapazität und mehr Budget absorbiert, als es sollte.

Schlussfolgerung

Die Software Due Diligence profitiert von einem tool-basierten Ansatz mit klar definierten KPIs. Er hilft, in relativ kurzer Zeit einen tiefen und plausiblen Einblick in die Risiken für die M&A-Transaktion zu erhalten. Allerdings müssen diese Tools mit Fingerspitzengefühl und Erfahrung eingesetzt werden, um falsche oder unvollständige Schlussfolgerungen zu vermeiden. 

So können beispielsweise Teile des Codes weniger wartungsintensiv sein, als es die Codequalität nur vermuten lässt. Im Gegensatz dazu ist die Architekturqualität eine zuverlässige Ursache für Hotspots in der Feature-Entwicklung. Die wichtigsten Fallstricke zu kennen und in der Lage zu sein, sie bei einer Due-Diligence-Untersuchung zu vermeiden, ist unerlässlich, um die richtigen Schlussfolgerungen aus einem tool-basierten Ansatz zu ziehen.