Interview mit Tammo van Lessen und Jörg Nitzsche

"Unter widrigen Umständen gut wartbaren Code schreiben – das lernt man viel zu wenig"

Hartmut Schlosser
© Software & Support Media

Wer kennt sie nicht: Die schnellen Workarounds, die man zur Einhaltung einer Deadline in Kauf nimmt. Doch die Gründe, warum man sich technische Schulden in einem Projekt einhandelt, sind vielfältig – wovon auch die JAX-Speaker Tammo van Lessen (innoQ) und Jörg Nitzsche (T-Systems) ein Lied singen können. Wir sprachen mit ihnen darüber, wie man technische Schulden vermeidet und weshalb hier der Vergleich mit der Finanzwelt helfen kann.

Technische Schulden sind eine Last, die man nur schwer los wird. Weshalb ist es aber so einfach, technische Schulden zu machen? Oder anders gefragt: Weshalb schreiben wir nicht gleich gut strukturierte, einfach wartbare Software?

Tammo van Lessen, Jörg Nitzsche: Zunächst zur Frage, weshalb es so einfach ist, technische Schulden zu machen. Das liegt daran, dass die Auftraggeber nur auf die Funktionalität schauen und ggf. ob die nichtfunktionalen Aspekte eingehalten werden können, nicht jedoch, ob die Software wirklich wartbar oder änderbar ist. Das ist schließlich zum Zeitpunkt der Erstellung nicht gefordert. Im Lastenheft werden in der Regel nur die gerade benötigten funktionalen und nichtfunktionalen Eigenschaften beschrieben. Änderbarkeit und Erweiterbarkeit sind als nichtfunktionale Anforderungen oft unterspezifiziert. Deshalb ist es schwierig, ein System von vorne herein sinnvoll änderbar zu gestalten, ohne die konkreten Arten von Änderungen zu kennen.

Nun zum zweiten Teil der Frage: Wir schreiben deshalb nicht gleich guten, strukturierten Code, weil wir nicht die Möglichkeit dazu bekommen. Jeder Entwickler hat zum Ziel, gut strukturierte Software zu schreiben, und hat dazu in der Ausbildung auch meist das richtige Rüstzeug erhalten. Was man leider viel zu wenig lernt, ist, wie man das auch unter widrigen Umständen schafft und wie man dafür Sorge trägt, dass eine existierende Software auf allen Ebenen wartbar bleibt, wie man die Erosion vermeidet. Die meisten Projekte beginnen ja leider nicht auf der grünen Wiese.

JAX Countdown
Der Countdown läuft: In großen Schritten nähern wir uns der JAX 2014, die in diesem Jahr vom 12. bis 16. Mai in Mainz stattfindet. Bis zum 10. April profitieren Sie noch von den Frühbucherpreisen – übrigens auch bei den parallel stattfindenden BigDataCon und Business Technology Days!
Alle Infos unter www.jax.de

Welche Arten von technischen Schulden gibt es?

Es gibt verschiedene Arten, eigentlich kann man sich auf allen Ebenen, wie Code, Architektur, Dokumentation, aber auch Teamarbeit und Führung Schulden einhandeln. Martin Fowler hat die Arten von Schuldenaufnahmen mit einem Quadranten mit den Spektren „rücksichtslos“ zu „besonnen“ und „vorsätzlich“ zu „versehentlich“ beschrieben. Vorsätzliche, besonnene Schulden kann man mit einer Baufinanzierung vergleichen. Die Gründe, die Schulden aufzunehmen, sind wohldurchdacht, das Risiko ist wohlkalkuliert. Dem gegenüber stehen die rücksichtlos, versehentlich aufgenommenen Schulden, z. B. weil man etablierte Architekturregeln nicht kennt. Vorsätzlich und rücksichtslos sind die schlimmsten Schulden. Beispielsweise einfach den Prototyp in Produktion nehmen, obwohl er als Prototyp konstruiert wurde, ist grobfahrlässig.

Wie lassen sich technische Schulden von vorne herein vermeiden?

Vermeiden lassen sich die Schulden zuallererst durch eine genaue Analyse der fachlich funktionalen und nichtfunktionalen Anforderungen, besonnene Architekturentscheidungen und einer Architektur mit Augenmaß. Außerdem muss man ein Umfeld schaffen, in dem die äußeren Umstände es zulassen, keine bleibenden Schulden zu machen.

Zudem ist es wichtig, auftretende Schulden frühzeitig zu erkennen und zu dokumentieren, um frühzeitig Gegenmaßnahmen ergreifen zu können. Als Indikatoren können verschiedene Projektkennzahlen herangezogen werden, z.B. die Anzahl kritischer Defects im Issue Tracker, steigende Aufwände für Änderungen oder Tests, Stress vor Deadlines im Team oder Angst vor Änderungen im Code.

Ihr habt ja bereits erwähnt, dass man es meist nicht mit einem neuen Projekt zu tun hat, sondern mit einer existierenden Codebasis, die sich schon den einen oder anderen Schuldschein eingehandelt hat. Wie reagiert man am besten auf solchen Legacy Code?

Hätte man den Schuldschein schon, könnte man ihn einfach abbezahlen. Das kann man beispielsweise durch die Einführung der Pfadfinderregel erreichen. Pfadfinder sind angehalten, den Campingplatz sauberer zu hinterlassen, als sie ihn vorgefunden haben. Für Entwickler gilt das gleichermaßen: Fällt beim Debugging eine schlecht programmierte Stelle auf, wird sie sofort verbessert. Auf diese Weise verbessert sich der Code kontinuierlich.

In der Praxis ist es aber leider so, dass man oft noch gar nicht weiß, dass man Schulden hat. Ähnlich wie ein Schuldenberater muss man sich erstmal einen Überblick verschaffen. Das geht z B. durch Code-Reviews, Erfassung von Code-Metriken, sorgfältige Analyse der Dokumentation etc. Auf dieser Basis muss man nun versuchen, das Vorgefundene zu bewerten, dann kann man Maßnahmen ergreifen.

Das erst kürzlich initiierte Projekt „aim42“ [1] nimmt sich der Problematik um den Umgang mit existierendem Code an und sammelt Muster für die drei Phasen „Analysieren“, „Bewerten“, „Verbessern“. Das Projekt pflegt einen offenen Musterkatalog [2] und nimmt gerne Ergänzungen und Kommentare entgegen. In diesem Katalog findet man schnell Mittel und Wege, die helfen, Schulden zu vermeiden oder abzubauen.

Ihr zieht in eurer JAX Session ja den Vergleich zur Finanzwelt. Inwiefern können Entwickler hier etwas lernen?

Der Vergleich mit der Finanzwelt kann Entwicklern helfen, die Probleme, die sich aus technischen Schulden ergeben, für die Entscheider verständlich zu machen. Dadurch kann man sie hoffentlich dazu bewegen, technische Schulden ernst zu nehmen und den Entwicklern den Spielraum zu geben, technische Schulden zu vermeiden oder abzubauen. Wie schon gesagt, Entwickler wollen ja guten Code schreiben. Durch unseren Vortrag lernen sie, wie sie ein Umfeld schaffen, in dem sie das auch tun können.

Vielen Dank für dieses Interview!

Tammo van Lessen arbeitet als Senior Consultant bei der innoQ im Bereich SOA/BPM und promoviert im gleichen Themengebiet. Er ist PMC Chair Apache ODE und Member der Apache Software Foundation. Außerdem hat er aktiv an der Standardisierung von BPMN 2.0 mitgewirkt und ist Mitautor des Buchs „Geschäftsprozesse automatisieren mit BPEL“. Tammo ist seit vielen Jahren professioneller Java-Entwickler und regelmäßger Sprecher auf nationalen und internationalen Konferenzen.

Dr. Jörg Nitzsche arbeitet als Senior IT Architect bei der T-Systems International im Bereich EAM/SOA/BPM. Er promovierte am Institut für Architektur von Anwendungssystemen der Universität Stuttgart und ist Mitautor des Buchs „Geschäftsprozesse automatisieren mit BPEL“.

JAX-Session: Vorsicht Schuldenfalle – was die IT aus der Finanzwelt lernen kann

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

5 Kommentare auf ""Unter widrigen Umständen gut wartbaren Code schreiben – das lernt man viel zu wenig""

avatar
400
  Subscribe  
Benachrichtige mich zu:
Christian Danninger
Gast

Links sind nicht korrekt. Die korrekten wären:
http://www.aim42.org/
http://aim42.github.io/

Marcel Koch
Gast

Der Link zu aim42 ist nicht korrekt. Hier hat sich ein Blank-Zeichen eingeschlichen. 🙂

Redaktion JAXenter
Gast

Links sind jetzt korrigiert. Vielen Dank für die Hinweise!

Anselm Garbe
Gast
Guter Artikel. Vieles kann ich so bestätigen. Was mir fehlt ist der Aspekt der Einfachheit. Software wird häufig aus den widrigen Umständen heraus (Projektsituation, Technologiemix, etc.) unnötigerweise verkompliziert und aufgebläht. Dies geschieht besonders durch unklare und wenig durchgesetzte Software-Prinzipien in vielen Produkten/Projekten. Für mich hat sich das UNIX Prinzip bewährt und hält bis heute Stand — Jede Softwarekomponente sollte nur eine Aufgabe erledigen und diese besonders gut. Dazwischen sollte es universelle und einfache Schnittstellen geben (im UNIX Sinne Streams oder Dateien). Dann bleiben die einzelnen Komponenten auch gut austauschbar. Wird so ein Prinzip angewendet, vereinfacht sich auch die Software-Architektur grundlegend… Read more »
twitter followers
Gast

We are a bunch of volunteers and opening a new scheme in our community.
Your website offered us with helpful info to work on.
You have done an impressive job and our whole neighborhood shall be thankful to you.