Buchrezension: Managing Software Debt

Cover: Managing Software Debt

Chris Sterling
Managing Software Debt
Building for Inevitable Change

Addison-Wesley
288 Seiten
€ 35,05
ISBN 978-0-3215-5413-0

Wer kennt das nicht: Man arbeitet in einem Software-Projekt und selbst die Implementierung einfachster Anforderungen ist unendlich mühsam. Unentwegt beschleicht einen das Gefühl, dass die Zeit gekommen ist, für all die „Hacks“ und „Quick Fixes“ seiner Kollegen zu bezahlen.

In seinem Buch „Managing Software Debt“ greift Chris Sterling genau dieses Phänomen auf. Auf 288 Seiten beschreibt er, wie Software-Schulden entstehen, welche Auswirkungen sie haben und wie sie bekämpft werden können. Das Buch ist gespickt mit Referenzen zum aktuellen Stand der Diskussion – beispielsweise zu Aufsätzen von Martin Fowler oder Ward Cunningham. Der Autor selbst ist ein erfahrener IT-Consultant, zertifizierter Scrum-Trainer und nach eigenem Bekunden passionierter Software-Entwickler. Die im Buch diskutierten Probleme und Lösungsansätze sind gut nachvollziehbar und wirken authentisch.

Software-Schulden – so die zentrale These – entstehen, wenn Anforderungen nur aufs Notwendigste umgesetzt werden, um einem unbarmherzigen Terminplan gerecht zu werden. Obwohl das Projekt zunächst erfreuliche Fortschritte macht, werden die provisorischen Lösungen zunehmend zu einem Problem, bis das Team letztendlich nur noch Code-Pflege betreibt. Die Wartungskosten der Software steigen und dennoch entsteht für den Anwender kaum noch Zusatznutzen.

Für eine eingehende Analyse dieses Phänomens trennt der Autor die Schulden-Metapher auf in Schulden in der technischen Umsetzung, in der Qualitätssicherung, im Konfigurationsmanagement, im Design und in der Organisation der Wissensweitergabe. Jedem Aspekt wird ein einzelnes Kapitel gewidmet.

Zum Kampf gegen Software-Schulden beschreibt der Autor Techniken, die zum Teil mit tradierten Denkmustern der Softwareentwicklung brechen. Eine Technik lautet „Architecture is S.A.I.D.“: Das „A“ steht für „Alignment“ und fordert dazu auf, die Architektur eines Softwaresystems mit den fachlichen Anforderungen und der Geschäftsstrategie des Unternehmens zu begründen. Die gängige Praxis hingegen betrachtet Architekturen meist als technische Herausforderung und degradiert die Fachlichkeit zur Randnotiz. Es entstehen nicht selten Ungetüme, bei denen das Attribut „over-engineered“ einer Verharmlosung gleichkommt.

Ein interessantes Merkmal des Buches ist die unerschöpfliche Zahl von Aphorismen. Wer wollte widersprechen bei „Acceptance tests are not sufficient as the entire test suite for ensuring quality.“ (S. 95) oder „Documentation can help somewhat but is prone to misinterpretation and lacks the appropriate detail.“ (S. 167) oder „[…] then people are moved around as „resources“ to keep them busy and persuade stakeholders that everything is being done to get their project finished.“ (S. 200). Als Leser möchte man unentwegt rufen: „Genau so ist es!“

Die unschätzbaren Erfahrungswerte des Autors sind leider mit einen leichten Dogmatismus gewürzt: Chris Sterling geht ziemlich unkritisch davon aus, dass agile Vorgehensweisen dem Problem des Code-Verfalls Einhalt gebieten könnten. Seine Argumentation lässt er in der Scrum-Methodik kulminieren. Ich bin hier sehr skeptisch, dass Scrum ein Allheilmittel darstellt. Wenn ein Projekt unter starkem Zeitdruck steht, wird auch Scrum wenig ausrichten können. Möglicherweise wird durch den Abnahmedruck am Ende jedes Sprints der Effekt sogar noch befördert.

Mein wichtigster Kritikpunkt erwächst aus der diffusen Definition von „Software-Schulden“: Da Software-Entwicklung immer unter Zeitdruck steht, wäre das Schuldenbegehen quasi unvermeidbar. Auch der im Buch beschriebene Moral Hazard (etwa: „Niemand wird herausfinden, dass genau ich die Schulden aufgenommen habe.“) lässt sich in der Realität kaum beobachten. Kein Entwickler produziert absichtlich schlechten Code. „Ja, das ist ein Quick Fix.“ ist oftmals schlicht eine Schutzbehauptung.

Plausibler erscheint da Ward Cunninghams Auffassung:

Software-Schulden entstehen dann, wenn der Entwickler es unterlässt, den Software-Code seinem geänderten Verständnis der Fachdomäne anzupassen. Der Code muss im Ergebnis so aussehen, als ob man schon immer gewusst habe, worauf die fachlichen Anforderungen hinauslaufen.

Das Problem ist also nicht ein fraglicher Programmierstil, sondern der Umgang damit, wie neue Erkenntnisse über die Fachdomäne in den Code einfließen. Wer hier das Problem bei den Entwicklern sucht, verkennt jedoch die Realität: Ist die aktuelle Software-Version einmal abgenommen, wird meist der darin enthaltene Code unantastbar. Genau dem gilt durch geeignete (Kommunikations-)Techniken entgegenzusteuern.

Kommentare sind abgeschaltet.