Seite 2: Probleme bei Brownfield-Projekten I

Inhaltsverzeichnis

Wo liegen die Probleme bei Brownfield-Projekten?

Bei Greenfield-, also auf der "grünen Wiese" gestarteten Projekten sind die Prinzipien von Clean Code Developer bereits von Anfang an einzusetzen. In sogenannten Brownfield-Projekten wurde möglicherweise gegen einige der Praktiken verstoßen. Welche Strategien stehen nun zur Verfügung, um auch solche Projekte so zu verbessern, dass sie den Werten der Initiative entsprechen? Ist es überhaupt sinnvoll zu versuchen, im Nachhinein Projekte zu verbessern?

Über einen längeren Zeitraum entwickelte Softwaresysteme kämpfen in der Regel mit einem grundlegenden Problem: Die innere Struktur wird immer schlechter. Man spricht sogar davon, dass der Code anfängt zu verrotten, oder vergleicht den Effekt mit der Entropie aus der Physik. Natürlich verrottet der Code nicht, aber die Effekte sind vergleichbar. Das pure Hinzufügen von Code reicht nämlich nicht aus, zwischendurch ist Unkraut zu jäten.

Mit jedem Versuch, eine Änderung an der Software vorzunehmen oder eine Funktion zu ergänzen, wird die Situation schlimmer: Der Code beginnt förmlich zu stinken. Die innere Qualität verschlechtert sich, in der Folge dauert es immer länger, Funktionen zu ergänzen.

Das Problem gestaltet sich sogar dramatischer, als man zunächst vermuten mag. Es verhält sich nicht linear, sondern exponenziell. Am Anfang sind die "unschönen Stellen" im Code noch überschaubar. Man hat zwar manchmal das Gefühl, irgendetwas sei falsch oder zumindest nicht ganz richtig, aber irgendwie bastelt man die neue Funktion doch noch hinein. Irgendwann werden die kritischen Stellen immer größer. Man versteht plötzlich seinen eigenen Code nicht mehr. Weil man sich nicht traut, den Code zu ändern, kopiert der Entwickler eben den Code und passt die Kopie an. Hier beginnen sich die Probleme zu verstärken: Plötzlich wurde ein Codebereich verdoppelt, und es besteht die Gefahr, dass beide Teile erneut verdoppelt werden. Der Code explodiert geradezu.

Im Prinzip sollten die Kosten für eine Funktion immer gleich sein, egal ob der Entwickler sie am Anfang implementiert oder erst zu einem späteren Zeitpunkt hinzufügt. In der Praxis sind nachträglich ergänzte Funktionen deutlich teurer – wohlgemerkt bei gleichem Umfang. Das liegt daran, dass Programmierer die innere Qualität der Software in aller Regel nicht auf Evolvierbarkeit auslegen. Dabei ist diese von Anfang an zu berücksichtigen, denn dieses innere Qualitätsmerkmal lässt sich nicht später hinzufügen. Damit ist nicht eine maximale Flexibilität gemeint, die für alles gerüstet ist und jegliche Ergänzung oder Veränderung mitmacht. Der Aufwand wäre zu hoch und würde sich betriebswirtschaftlich nicht darstellen lassen. Gemeint ist eine Struktur, die sich mit wirtschaftlichem Aufwand an den Stellen, an denen es sich als erforderlich erweist, anpassen lässt. Dabei liegt der Fokus nicht darauf, zu jedem Zeitpunkt maximale Qualität anzustreben. Sie sollte angemessen sein und Veränderung sowie Erweiterung ermöglichen.

Exponenziell steigende Kosten

Wenn die innere Struktur und Qualität einer Software das Ergänzen von Funktionen erschwert, steigen die Kosten. Auch das Anpassen von Funktionen an geänderte Rahmenbedingungen verursacht immer höhere Kosten. Schließlich führt der Aufwand für manuelles Testen zu höheren Ausgaben. Irgendwann sind sie so groß, dass keine Funktionen mehr ergänzt werden, weil das betriebswirtschaftlich nicht sinnvoll wäre. Soll die Software trotzdem im Einsatz bleiben, steigen die Support-Kosten, und will man die Software weiterhin vermarkten, steigen mitunter die Kosten für höheren Marketingaufwand, weil sich der Überzeugungsaufwand immer größer gestaltet.

Eine große Gefahr der ansteigenden Kosten ist, dass der Anstieg nicht linear erfolgt. Das liegt daran, dass sich die Probleme anhäufen und gegenseitig verstärken. So werden steigende Kosten am Anfang eines Softwareprojekts oft nicht als problematisch erkannt. Man geht davon aus, dass die Kosten später wieder sinken. Die strukturellen Fehler führen jedoch dazu, dass die Probleme später immer größer ausfallen, wenn man sie nicht von Anfang an eindämmt. Sind erst tausende Zeilen schlechten Codes angesammelt, fällt es schwer, wieder Ordnung herzustellen. Und je länger man diesen Prozess hinausschiebt, desto teurer wird er.

Notwendige Veränderungen

Da es relativ lang dauert, bis sich die Auswirkungen einer unprofessionellen Arbeitsweise an steigenden Kosten ablesen lassen, ist es meist zu spät für Eingriffe, die wenig Aufwand verursachen. Wenn man nicht ständig die Qualität der Software im Blick hat, wird das Problem schleichend immer größer, bis es am Ende so groß ist, dass zu seiner Behebung massive Veränderungsprozesse einzuleiten sind. In aller Regel betreffen die Veränderungen nicht nur die Arbeitsweise, sondern auch den Entwicklungsprozess. Damit fordert man Entwickler heraus, sich einerseits mit neuen Prinzipien und Praktiken auseinanderzusetzen, andererseits sind sie mit Veränderungen in der Organisation ihrer täglichen Arbeit konfrontiert.

Die nötigen Veränderungen sind in der Regel so umfangreich, dass sie zum einen relativ teuer sind und zum anderen die Gefahr droht, dass sie sich nicht erfolgreich umsetzen lassen. Veränderungsprozesse haben einen typischen Verlauf: Wenn man mit ihnen beginnt, sinkt die Produktivität ab, um dann wieder anzusteigen. Vertraut man nicht darauf, dass nach dem Abstieg ein Aufstieg auf ein höheres Niveau erfolgt, brechen die Beteiligten den Veränderungsprozess möglicherweise zu früh ab und scheitern. Vor allem das Vertrauen des Managements gegenüber den Entwicklern ist hier gefragt. Aber auch Entwickler müssen sich gegenseitig vertrauen und davon ausgehen können, dass jeder nach Kräften sein Bestes gibt.