Schlechtes Verhalten von Sofware-Architektur

Warum Programmierer an ihren Software-Systemen riechen müssen

Coman Hamilton

© Shutterstock / bimka

Wenn Ihr Softwaresystem langsam ist und Schwierigkeiten damit hat, sich „weiterzuentwickeln“, ist es gut möglich, dass ihr Team nur eindimensional arbeitet, sagt Gernot Starke, Experte für das Verhalten von Softwarearchitektur.

Nehmen wir einmal an, Sie waren ein ungezogener Entwickler und haben nicht darauf geachtet, ihren Code sauber und ordentlich zu halten. Dann stehen die Chancen gut, dass Ihr Manager einen Softwarearchitektur-Consultant wie Gernot Starke anruft, der darauf spezialisiert ist, was in Systemen schief läuft. Wir haben im Rahmen des Software Architecture Summit in Berlin mit ihm gesprochen.

JAXenter: Gernot, als Autor des bekanntesten deutschen Ratgebers zu den Dos und Dont’s in der Softwarearchitektur sind Sie eine Art Berühmtheit in der deutschen Softwarearchitektur-Szene. Vielleicht können Sie uns zunächst einmal sagen, was die wichtigsten Regeln sind, die Softwarearchitekten gerne vergessen?

Gernot Starke: [Lacht] Soll damit wirklich ich gemeint sein? Ich glaube, in vielen Bereichen haben wir einvernehmliche Übereinkünfte bezüglich des Grundlagenwissens, bewährter Praktiken und guter Handlungsweisen. Und wir neigen dazu, diese zu vergessen, wenn wir dem Stress des Tagesgeschäft ausgesetzt sind, unter dem Druck stehen, schnelle Resultate zu liefern und unsere Chefs dringende Reparaturen verlangen. Wir neigen dann dazu, das alles beiseite zu schieben und schnelle Lösungen umzusetzen. Wir machen das in allen Bereichen, bei den Prozessen, der Architektur, der Struktur, dem Code und so weiter. Und wenn ich Klienten aufsuche, wissen sie um die Standards in alle diesen Bereichen und ihnen ist klar, welche Probleme sie damit haben. Aber sie schieben dieses Wissen aus so genannten „guten Gründen“ zur Seite (auch wenn sie später nicht erklären können, was diese „guten Gründe“ waren.)

Es ist wie mit dem Zähneputzen: Manchmal vergisst man es zwar, aber das ist nicht so schlimm. Aber man darf es nicht grundsätzlich ignorieren. Das weiß jedes Kind. In der Softwarearchitektur aber putzen wir uns nicht mehr die Zähne. Wir gehen einfach so zu Bett!

In der Softwarearchitektur putzen wir uns aber nicht mehr die Zähne.

Das ist das eine. Doch auch das Gegenteil ist ein Problem: Das Streben nach Perfektion. Wir sind letztes Mal gescheitert, oder zumindest ein bisschen. Und dieses Mal versuchen wir, es besser zu machen. Wir verwenden mehr und bessere Technologien, wir versuchen besser Experten an Bord zu holen, wir versuchen die Dokumentation zu verbessern, ein besseres System zu bauen, in jeder nur denkbaren Hinsicht besser zu sein. Aber wir vergessen dabei, dass Veränderungen auch ein Risiko darstellen können. Also ignorieren wir diese Risiken manchmal. Perfektion ist der Feind des Guten. Wenn Sie versuchen perfekt zu sein, finden Sie nicht den richtigen Ausstiegspunkt und machen damit weiter, etwas zu optimieren, das gar nicht optimierenswert ist.

Das ist das andere. Und das Management neigt dazu, diesen Perfektionismus ganz genau zu bemerken und die verantwortlichen Leute zu bestrafen. Dabei reagieren die Verantwortlichen oft über und werfen alle guten Ideen über Board, um erneut mit einer schnellen Lösung daher zu kommen. Und schon fängt man wieder bei Null an.

Ich spreche regelmäßig mit Architekten, die große Systeme betreuen und neue Komponenten dafür entwickeln. Sie berichten mir vom ständigen Wechsel zwischen einem „Reparatur Modus“ (wir müssen dieses Problem so schnell wie möglich lösen, weil etwas still steht und darauf wartet, repariert zu werden) und einer entspannten Haltung, die von der Idee geprägt ist, alles wegzuwerfen und von vorne anzufangen. Beide sind nicht angemessen, aber dafür gibt es kein echtes Maß. Man kann keinen Algorithmus dafür entwickeln und ihn jeden Tag durchlaufen lassen. Die traditionelle Hausfrau wusste ganz genau, wie ein Haushalt organisiert wird. Manchmal denke ich, wir verlieren diese Art des gesunden Menschenverstands. Wenn man Entwickler an ihren gesunden Menschenverstand erinnert, sind manche ganz erstaunt und denken „Oh, klar! Wie konnte ich das nur tun?!“.

Und das ist es, was ich versuche den Leuten als Werkzeug an die Hand zu geben: Erinnert euch selbst daran, euren gesunden Menschenverstand zu benutzen um euch selbst Feedback zu geben.

Gernot Starke and Coman Hamilton in conversation (© S&S Media)

Gernot Starke und Coman Hamilton im Gespräch (© S&S Media)

Im Rahmen des Software Architecture Summit haben Sie über die typischen Probleme in der Softwarearchitektur gesprochen…

Ja, und darüber, wie man sie findet.

Also, wie findet man sie?

Ich habe mir eine Analogie dazu überlegt. Stellen Sie sich vor, ihre Verlobte kommt zu Besuch zu Ihnen nach Hause und Sie möchten ein großartiges Essen für sie kochen. Sie bereiten alles vor, kaufen ausgefallene Zutaten und rühren alles zusammen. Aber das einzige, was Sie testen, ist die Temperatur des Essens. Sie probieren nichts, kontrollieren die Konsistenz nicht, riechen nicht am Essen. Nur die Temperatur wird gemessen. Niemand würde das tun es ist hochgradig riskant. Außer bei Toastbrot, das kann man einfach in den Toaster stecken und muss sich um nichts weiter kümmern.

An der Software riechen

Bei Software arbeiten wir jedoch mit so vielen Dimensionen, in denen wir Fehler, Probleme und Risiken für unsere Systeme verursachen können, einfach weil sie so komplex sind. Wir können die Daten durcheinander bringen, Querschnittsthemen versauen. Und normalerweise schauen sich die Beteiligten auch nur ihren eigenen Quellcode an. Sie nutzen nur eine Dimension, um das Problem zu finden. Und dann versuchen sie dieses Problem zu lösen, indem sie die Suppe ein bisschen heißer machen. Aber sie schmeckt immer noch nicht gut. Die Temperatur mag zwar stimmen, die Code-Metrik richtig sein, aber man wundert sich immer noch, warum das Endergebnis so schlecht ist. Ein guter Koch würde Ihnen darauf antworten, dass Sie am Gericht riechen müssen. Es geht um eine andere Dimension. Auch in der Software sollte die Temperatur nicht das einzige sein, was betrachtet wird.

Sie müssen den Prozess betrachten, wie die Software entsteht. Wenn der Prozess nicht zum Problem oder der Struktur des Teams passt, ist das schlecht. Man muss auf die technische Infrastruktur schauen. Wenn der Code stimmt, aber die Infrastruktur nicht, wird der Code nicht schnell genug laufen und man bekommt Probleme.

Sie sprechen oft über die „evolutionäre Verbesserung“ von Software. Was meinen Sie damit?

Wir haben viele Systeme, die über 10 oder mehr Jahre hinweg laufen und gepflegt werden. Das ist eine wirkliche lange Zeit. Man investiert jedes Jahr in diese Systeme, also addieren sich diese Investitionen zu einer sehr, sehr großen Menge Geld. Also müssen wir die Summe minimieren, die notwendig ist, um ein System am laufen zu halten. Wir reden hier über sehr viel Geld  nicht über Tausende, sondern Hundertausende und Millionen. Je einfacher es also wird, ein System zu pflegen, desto günstiger wird es auch. Es ist eine Kostenfrage – oder eine Wertfrage.

Je einfacher es also wird ein System zu pflegen, desto günstiger wird es auch.

Mit „evolutionärer Verbesserung“ meine ich, dass die Situation normalerweise täglich unübersichtlicher wird. So als ob Sie zu Hause nie aufräumen würden, keinen Geschirrspüler haben, die Fenster nicht putzen, die Regale nicht abstauben. Wir nennen solche Menschen „Messies“. Niemand will in so einem Haus leben. Viele Software-Systeme sehen aber aus wie das zu Haus eines Messies. Es macht keinen Spaß mehr, damit zu arbeiten und wenn hochqualifizierte Leute verloren gehen, wird es sehr schwer, neue Funktionen hinzuzufügen. Das System wird mit der Zeit langsamer. Und dann übt das Management mehr Druck aus, weil Sie Ihre Deadlines beim letzten Mal nicht eingehalten haben und sie auch dieses mal nicht einhalten werden. Mit Evolution meine ich, dass wir genau das vermeiden wollen. Wir wollen Spaß an der Arbeit haben und unsere Manager bei Laune halten.

Aufmacherbild: Nose of dog, my lovely chihuahua von Shutterstock / Urheberrecht: bimka

Verwandte Themen:

Geschrieben von
Coman Hamilton
Coman Hamilton
Coman was editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous websites and magazines, as well as several ad agencies.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.