W-JAX Countdown mit Carola Lilienthal

'Wenn meine Entwickler Schätzungen machen, schlage ich immer 100% drauf'

Hartmut Schlosser
Dr. Carola Lilienthal

Wer kennt das nicht: Vorab wird eine geniale Softwarearchitektur entworfen, alle sind zufrieden damit und man beginnt mit der Implementierung – doch das Ergebnis sieht am Ende ganz anders aus. Warum Entwickler sich immer wieder von Architektur-Plänen entfernen – und was man tun kann, um wieder auf Kurs zu kommen –, haben wir mit W-JAX-Speakerin Dr. Carola Lilienthal besprochen.

JAXenter: Woran liegt es, dass Entwickler immer wieder von Architektur-Vorgaben abweichen?

Carola Lilienthal: Eine Antwort auf diese Frage kennen wir alle nur zu gut: Entwickler weichen bei der Implementierung vom Architekturentwurf ab, weil sie aus Zeitmangel und Projektdruck Abkürzungen gehen oder keine Zeit für Refactorings haben, die sie wieder zurück zur geplanten Architektur bringen würden. Meistens sind sich die Entwickler all dieser Probleme bewusst, kommen aber nicht dagegen an, weil die Software fertig werden muss.

Darüber hinaus beobachte ich, dass die Entwicklungsteams oft nicht in der Lage sind, oder keine Tools haben, um kontinuierlich überprüfen zu können, ob ihre Implementierung der Architektur weiterhin entspricht. So verstoßen die Entwickler oft unbemerkt gegen die Vorgaben der Architektur. Hinzu kommt noch, dass die Entwickler erst beim Implementieren auf Probleme stoßen, die sie mit der gegebenen Architektur nicht lösen können. Hier müsste die Architektur eigentlich weiterentwickelt werden, und dafür fehlt oft das Gremium oder die Zeit.

JAXenter: Man könnte jetzt etwas radikal sagen: Wenn die Architektur-Entwürfe nicht eingehalten werden – wozu brauchen wir sie dann? Könnte sich eine Architektur nicht auch schrittweise auf der Basis vieler kleiner Entscheidungen während des Entwicklungsprozesses – quasi von unten heraus – entwickeln?

Carola Lilienthal: Ich habe schon viele Softwaresysteme analysiert, bei denen sich die Architektur mit der Zeit entwickelt hat. Es waren in den meisten Fällen keine einfach wartbaren und leicht verständlichen Softwaresysteme. Ausnahmen waren hier Teams, die schon sehr viel Konstruktionserfahrung hatten und deshalb implizit eine gute Architektur entwickelt haben.

Leider können wir Software nicht immer nur von erfahrenen Teams entwickeln lassen. Unerfahrene Teams brauchen Vorgaben, wie sie ihr am Ende sehr großes und komplexes Softwaregebilde strukturieren sollen und welchen Qualitätskriterien sie dabei einhalten müssen. Die Softwarearchitektur gibt dem Entwicklungsteam dann quasi Leitplanken vor, in deren Rahmen sie entwickeln, und lenkt so alle auf einen gemeinsamen und dauerhaften Weg.

JAXenter: Meine Erfahrung ist, dass Projektdruck – und damit oft auch Abweichungen von einem Architekturplan – dann entsteht, wenn Aufwandsschätzungen falsch vorgenommen wurden. Oft wird von der Prämisse ausgegangen – „Wenn alles optimal läuft, dann schaffen wir das bis…“ Die Trial/Error-Phase, also der Prozentsatz des unvermeidlichen Scheiterns, wird unterschlagen – sicher auch, weil das einem Management schlecht zu vermitteln ist. Weshalb liegen aus Ihrer Sicht Aufwandschätzungen regelmäßig daneben?

Carola Lilienthal: Wenn meine Entwickler Schätzungen machen, dann schlage ich immer noch einmal 100% drauf. Die Schätzungen werden meistens mit einer positiven Einstellung gegenüber der Software und dem eigenen Können vorgenommen. Allerdings ohne die Problemstellung ganz durchdrungen zu haben – sonst hätte man die Lösung ja bereits programmiert. Dadurch kommen zu geringe Schätzungen zustande.

Außerdem wird oft die Tatsache vergessen, dass die eigene Anpassung an der Software nicht alleine die Lösung darstellt, sondern dass Integrationsarbeit mit anderen Softwaresystemen zu leisten ist. Dieser Integrationsaufwand wird bei Schätzungen häufig nicht berücksichtigt, weil die Entwickler sich nur in ihrem eigenen System bewegen.

[ header = Seite 2: Technische Schulden – und wie man sie wieder los wird! ]

JAXenter: Im Zentrum Ihres Vortrages auf der W-JAX steht der Begriff „technische Schulden.“ Was für Arten von technischen Schulden kann es geben?

Carola Lilienthal: Der Begriff „technische Schulden“ ist eine wunderbare Metapher, um Managern verständlich zu machen, warum Software renoviert, gepflegt und gewartet werden muss. Über verschiedene Arten von technischen Schulden habe ich bisher noch nicht nachgedacht. Spontan fallen mir die folgenden ein:

1. stark verkoppelte monolithische Softwarestruktur
2. veraltete Technologien
3. fehlende Testabdeckung

1) und 3) führen dazu, dass Änderungen und Erweiterungen mit der Zeit immer aufwendiger und gefährlicher werden, weil die Auswirkungen vorab nicht überschaubar sind. 2) führt hauptsächlich dazu, dass die Software nach einiger Zeit auf Technologie beruht, die nicht mehr weiterentwickelt wird und so das gesamte System von der technologischen Weiterentwicklung abgehängt wird.
 
JAXenter: Ich kenne eigentlich kein Projekt, das man als frei von technischen Schulden bezeichnen könnte. Denken Sie, dass es überhaupt möglich ist, technische Schulden von vorne herein zu vermeiden?

Carola Lilienthal: Kein Projekt wird jemals ganz frei von technischen Schulden sein. Das stimmt. Genauso wie unsere Wohnungen oder unser Arbeitsplatz nie ganz aufgeräumt sind. Das ist nicht möglich. Aber selbstverständlich ist es möglich, mit der nötigen Aufmerksamkeit von Anfang an, auf technische Schulden zu achten und ihr Ausmaß einzudämmen. Es kommt hin und wieder vor, dass ich Software analysieren darf, die neben einiger Mängel im großen und ganzen in einem guten Zustand ist.

Der schönste Moment bei solchen Analysen ist, wenn ich den zuerst überraschten und dann glücklichen Entwicklern mein Lob für Ihre gute Arbeit aussprechen darf. In diesen Fällen sind die technischen Schulden überschaubar und das Qualitätsbewusstsein ist im ganzen Team zu spüren.  

JAXenter: Wie wird man technische Schulden wieder los?

Carola Lilienthal: Viel häufiger als zu schuldenfreien Systemen werde ich zu Softwaresystemen gerufen, bei denen das Kind bereits in den Brunnen gefallen ist.

Sind sich alle Beteiligten darüber im Klaren, dass etwas getan werden muss, dann kann ich mit dem Entwicklungsteam in zwei bis drei Tagen die Architektur und die passenden Refactoring-Maßnahmen erarbeiten und sie priorisieren. Ähnlich wie in einem agilen Prozess ist es auch bei Architekturerneuerungen besser, wenn man in kleinen Schritten vorgeht. Insofern mache ich keine Langzeitanalysen oder schreibe ausführliche Berichte, sondern treffe mich lieber regelmäßig mit den Entwicklungsteams, schaue mir die Fortschritte in der Software an und erarbeite die nächsten Schritte, um weitere technische Schulden abzubauen.

Werde ich zu einem Entwicklungsteam gerufen, bei dem nicht alle Beteiligten überzeugt sind, dass sich etwas ändern muss und schon gar nicht in welche Richtung die Änderungen gehen sollen, dann ist so eine Architekturanalyse eher eine Mediation. Meine Aufgabe ist dann, aufgrund meiner Erfahrung alle Interessen auszugleichen und Spannungen abzubauen. Solche Situationen treten auf, wenn ein Auftraggeber will, dass ich die Software eines Dienstleisters analysiere. Hier ist der Weg oft nicht so gradlinig, weil viele politische und finanzielle Randbedingungen berücksichtigt werden müssen.

JAXenter: Vielen Dank für dieses Interview!

Dr. Carola Lilienthal ist Senior Softwarearchitektin bei der Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Sie hat an der Universität Hamburg studiert und dort zum Thema „Komplexität von Softwarearchitekturen“ promoviert. Seit 2003 analysiert sie im Auftrag ihrer Kunden in ganz Deutschland regelmäßig die Architektur von Softwaresystemen und fasst die Ergebnis in Qualitätsgutachten zusammen. Insgesamt hat Dr. Carola Lilienthal über fünfzig Softwaresysteme zwischen 30 000 und 15 Mio. LOC untersucht.

Dr. Carola Lilienthal auf der W-JAX 2014: Komplexe Architekturen schuldenfrei weiterentwickeln

Kennen Sie das auch? Sie entwerfen eine gut strukturierte Softwarearchitektur in Form von Diagrammen und nutzen sie als Blaupause für Ihr Softwaresystem. Während der Implementierung weichen Ihre Entwickler ungewollt mehr und mehr von diesen Vorgaben ab: Einerseits macht der Projektdruck Abweichungen notwendig, andererseits entstehen die Abweichungen ungewollt und unbemerkt. Die Architektur Ihres Systems erodiert und Sie bauen Schritt für Schritt technische Schulden auf. Wartung und Erweiterung der Software werden immer teurer bis zu dem Punkt, an dem jede Änderung zu einer schmerzhaften Anstrengung wird. In diesem Vortrag berichte ich von meinen Erfahrungen der letzten zehn Jahre mit der Analyse von Softwarearchitekturen in Java, C++, C# und ABAP: Wie entstehen technische Schulden? Wie können technische Schulden vermieden werden?

Um technische Schulden sichtbar zu machen und ihnen rechtzeitig entgegenzusteuern, wurden in den letzten zehn Jahren verschiedene Architekturanalysewerkzeuge entwickelt (Sotograph, SonarQube, JDepend, XRadar, Axovion Bauhaus, Structure101, Lattix u.v.m.). Ich werde Ihnen im Vortrag einen Überblick über diese Werkzeuge und ihre Einsatzmöglichkeiten geben. Die Zuhörer wissen nach meinem Vortrag, welche Fehler sie in ihren Softwareprojekten bei der Umsetzung der Architektur in Sourcecode nicht machen sollten, welche Prinzipien Sie einhalten sollen, um technische Schulden nicht entstehen zu lassen, welche Tools helfen, technische Schulden aufzuspüren und wie technische Schulden abgebaut werden können.

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

9 Kommentare auf "'Wenn meine Entwickler Schätzungen machen, schlage ich immer 100% drauf'"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Perfetti
Gast

Deutet der Einsatz von COBOL und hierarchischen Datenbanksystemen bereits auf technische Schulden hin? Siehe Punkt 2 – veraltete Technologien – oder wäre das zu pauschal?

Flapsig ausgedrückt: macht COBOL einen Gang zur Schuldnerberatung notwendig? Oder bleibt einem gar nur noch die Privatinsolvenz?

Carola
Gast

🙂 sehr schöne Frage! Ich meinte mit veralteter Technologie die im jeweiligen Kontext veralteten Anteile. Insofern: Nein! COBOL ansich ist keine technische Schuld. Ich habe selbst COBOL programmiert und auch in dieser Sprache kann man mit wenig Schulden (schuldenfrei schafft niemand) programmieren.

Matthias
Gast

Die Aussage "Wenn meine Entwickler Schätzungen machen, dann schlage ich immer noch einmal 100% drauf" halte ich für sehr bedenklich.

Ich stelle es mir nicht gerade motivierend vor wenn meine Schätzung so wenig Beachtung findet bzw. davon ausgegangen wird das ich als Entwickler die "Problemstellung ganz durchdrungen zu haben".

Ganz nach dem Motto: "Der dumme Entwickler weiss sowieso nicht wovon er spricht".

Carola
Gast

hm, wenn Sie da so verstehen, dann tut es mir leid! Vor meinen Entwicklern/Kollegen halte ich sehr viel. 'dumm' sind sie auf keinen Fall.
Wenn ich selbst in der Entwickler- und Schätzer-Rolle bin, dann erwische ich mich aber auch oft dabei, dass ich zu positiv schätze, und ärgere mich später, was alles noch hinzukommt.
Ich versuche also eher uns alle zu schützen, damit wir Zeit haben gute Qualität abzuliefern. Geht es Ihnen nicht so?

Tom Seidel
Gast
Die werte Frau scheint es ja genau zu wissen. Nach meiner Erfahrung haben falsche Schätzungen (egal in welche Richtung) oftmals was mit den Rahmenbedingungen zu tun unter denen geschätzt werden muss, entweder sind die Anforderungen noch nicht ganz klar, die Akzeptanzkritierien noch nicht definiert oder die Aufgabe wird dem Entwickler einfach "über den Zaun geworfen". Sich dann hinzustellen und dem Entwickler die Kompetenz einer realistischen Schätzung mir-nix-dir-nix einfach abzuerkennen und ihm vorzuwerfen er habe das Problem nicht "durchdrungen" zeugt weder von Teamgeist noch von starker Führungspersönlichkeit. Klar, kann es vorkommen, dass man zu positiv schätzt, die Begründung dafür ist aber… Read more »
Carola
Gast

Werter Herr Seidel, es macht mir keine Freude Ihren Kommentar zu lesen – er steckt voller Angriffe auf mich als Person – halten Sie das für einen guten Zug? Sprechen Sie mich auf der W-JAX doch einfach an, dann können wir persönlich diskutieren und sehen, ob wir wirklich so viele Differenzen haben.

Uwe Hehn
Gast
Sehr geehrte Frau Dr.Lilienthal, die Ansichten die Sie in diesem Interview vertreten sind teilweise ein solcher Unsinn dass sich mir die Haare sträuben. Einzelne Entwickler nicht-triviale Umfänge oder Problemstellungen schätzen zu lassen, ist an sich zum Scheitern verurteilt. Sie haben als PL nur dann eine klitzkleine Chance eine einigermassen belastbare Schätzung zu bekommen, wenn Sie das ganze (gut eingespielte Team) möglichst kleine, gut definierte Aufgabenteile schätzen lassen. Haben Sie zu jedem Zeitpunkt Ihres Projektes diese Aufgabenteile *für das gesamte restliche Projekt* definiert? Meistens weiss doch noch nicht mal der Kunde alle Einzelheiten… Und noch was: technische Schulden, gerissene Zeit- und… Read more »
TestP
Gast

Also ich finde die Schätzung "geschätzter Zeitraum" * 2 schon ganz OK. In der Praxis passt es halt. Als Programmierer vergisst man schnell die technischen Schwierigkeiten und das Umschiffen derer mit irgendwelchen Fremdprodukten.

Grüße

Jakob
Gast

Das Entspricht auch meiner Erfahrung. Hier gibts auch ein paar weitere Gründe dafür warum das so ist: http://jaxenter.de/news/Warum-Entwickler-hoffnungslose-Optimisten-sind