Des Entwicklers Angst

Entwickler haben ein ungutes Gefühl, wenn sie an Software mit schlechter innerer Struktur arbeiten müssen. Sie sind ständig von der Angst ergriffen, etwas zu zerstören. Da automatisierte Tests, wenn überhaupt, nicht im erforderlichen Umfang zur Verfügung stehen, müssten sie bei jeder Änderung oder Ergänzung die gesamte Software erneut manuell testen. Das ist im erforderlichen Umfang jedoch schlicht nicht realisierbar. Also testet man nur Bereiche, an denen der Entwickler gearbeitet hat. Oft handelt es sich bei Eingriffen in die Software jedoch nicht um eng begrenzte Bereiche. Das liegt daran, dass die Implementierung eben nicht nach den "Regeln der Kunst" erfolgt ist. Bei vielen Ergänzungen oder Änderungen ist demnach an diversen Stellen einzugreifen, was das Testen enorm erschwert. Auch hier liegt ein sich selbst verstärkender Prozess vor: Weil die innere Struktur so schlecht ist, ist oft an vielen Stellen zu ändern. Dadurch wird die Struktur im Laufe der Zeit noch schlechter, die Angst, etwas zu zerstören, noch größer. Selbst lokale Änderungen führen häufig zu unerwarteten Problemen an scheinbar nicht betroffenen Stellen, weil keine saubere Trennung vorliegt. Weil man Angst hat, etwas kaputt zu machen, traut man sich nicht, für die erforderlichen Ergänzungen eine punktuelle Verbesserung der Struktur vorzunehmen. Dadurch wird beim nächsten Mal die Angst noch größer.

Jeder Mensch dürfte schon mal die Abneigung verspürt haben, durch eine Straße zu gehen, in der überall Müll herumliegt. So ergeht es Softwareentwicklern beim Blick auf schlechten Code. Sie verspüren eine innere Abneigung dagegen, sich mit dem Code auseinanderzusetzen. Wie sich in einer Straße der Unrat weiter ansammelt, wenn ihn niemand wegräumt, sammelt sich schlechter Code an. Da der Code den Eindruck vermittelt, es käme nicht darauf an, gute Qualität abzuliefern, wird ein Entwickler seine Ergänzungen tendenziell in gleich schlechter Qualität abliefern.

Manuelle Arbeiten

In Brownfield-Projekten trifft man häufig auf manuelle Handarbeit. Beispielsweise ist der Build- und Release-Prozess oft nicht automatisiert. Steht eine Version zur Auslieferung an, sucht der Entwickler in mühsamer Handarbeit alles zusammen, was zur Verteilung erforderlich ist. Neben der Tatsache, dass die Tätigkeit nicht gerade mit Spaß verbunden ist, besteht das Risiko, Fehler zu machen. Entwickler vergessen Komponenten, Modulversionen passen nicht zusammen, ein erforderliches Datenbank-Update unterbleibt et cetera. Es soll sogar Projekte geben, in denen nicht einmal ein Versionskontrollsystem zum Einsatz kommt.

Auch das Testen der Anwendung erfolgt oft manuell. Da die innere Struktur es nicht zulässt, einzelne Funktionen isoliert zu testen, bleibt nur, Integrationstests durchzuführen. Sie lassen sich automatisieren, jedoch herrscht oft der Glaube vor, das würde sich nicht lohnen. Stattdessen testet man am Ende viel zu wenig.

Die manuellen Arbeiten führen noch zu einem weiteren Problem: Die Rückmeldung an die Entwickler dauert vergleichsweise lange, weil sich die manuellen Tätigkeiten nicht so oft und nicht schnell ausführen lassen. Entwickler sammeln mehrere neu implementierte Funktionen, ehe sie einen manuellen Integrationstest durchführen. Das führt dazu, dass der Programmierer erst spät eine Rückmeldung darüber erhält, ob die implementierte Funktion korrekt ist. Es fallen überflüssige Arbeiten an, die vermeidbar wären, wenn die Rückmeldung früher eingetroffen wäre.

Manuelle Arbeiten lassen sich nicht in allen Fällen vermeiden. Oft sind jedoch Automatisierungen mit wenig Aufwand möglich, und das reduziert nicht nur die Kosten, sondern erhöht gleichzeitig die Qualität.

Abkopplung von aktuellen Entwicklungen

Ein häufig zu beobachtendes Problem von Brownfield-Projekten ist die Abkopplung von aktuellen Entwicklungen. Wer immer noch mit Visual Basic 6 (VB6) entwickelt, hat beispielsweise keinen Zugriff auf aktuelle Techniken im Bereich der Entwicklungsumgebungen. Aktuelle IDEs bieten komfortable und leistungsfähige Unterstützung für Refaktorisierungen. In VB6 ist das nicht verfügbar. Ohne Werkzeugunterstützung sind Refaktorisierungen aufwendig und damit teuer. Ferner steigt das Risiko, neue Fehler zu verursachen, wenn die Refaktorisierungen nicht automatisiert erfolgen können.

Des Weiteren kann es auf technischer Ebene eine Abkopplung von aktuellen Entwicklungen geben: Soll beispielsweise eine Anwendung, die bislang nur als Windows-Applikation zur Verfügung steht, auch im Web verfügbar sein, bedeutet das bei einer monolithischen Anwendung eine komplette Neuentwicklung. Nur eine Applikation mit einer guten inneren Struktur lässt sich mit vertretbarem Aufwand so anpassen, dass der Kern der Anwendung sich unter einer anderen Oberfläche weiternutzen lässt. Anwendungen, die sich nicht in kurzer Zeit an aktuelle technische Entwicklungen anpassen lassen, haben einen Wettbewerbsnachteil. Kann der Mitbewerber beispielsweise in kurzer Zeit eine Serviceschnittstelle über das REST-Protokoll anbieten, kann das ein entscheidender Vorteil sein. Ob man es im konkreten Fall tatsächlich tun möchte, ist eine Entscheidung, die wohl überlegt sein will. Es sollte aber strukturell umsetzbar sein. Das Risiko besteht darin, eine aktuelle Entwicklung als "Hype" abzutun, obwohl es in Wirklichkeit durch strukturelle Fehler gar nicht möglich ist, sie umzusetzen.

Personalmangel als Teufelskreis

Wer bewirbt sich auf eine Stelle, für die der Inserent Kenntnisse in "uralten" Programmiersprachen fordert? Oft sind das Softwareentwickler, die nur diese Sprache beherrschen und die lange nicht in persönliche Weiterentwicklung investiert haben. Solche Entwickler sind in gewissem Umfang erforderlich, aber man wird sie kaum zu denen zählen, die für Innovation und Weiterentwicklung im Unternehmen sorgen. Damit zeigen sich gleich zwei Probleme: Entwickler, die in der Lage sind, die alten Systeme weiterzupflegen, sind nur schwer zu bekommen. Wenn man sie dann hat, sind sie in aller Regel nicht die Spitzenkräfte, die in der Lage wären, für Weiterentwicklung und Innovation zu sorgen. Da sich das Unternehmen mit seinen Altlasten herumplagt, ist es wenig attraktiv für Spitzenkräfte, die sich ständig weiterentwickelt haben. So entsteht ein sich selbst verstärkender Teufelskreis.

Mangelhafter Prozess

Oft ist in Brownfield-Projekten, die seit längerer Zeit laufen, der Prozess der Softwareentwicklung nicht angemessen. Es wird nach wie vor versucht, Softwareprojekte mit wasserfallartigen Prozessen durchzuführen. Doch das gelingt nur in seltenen Fällen. Softwareprojekte sind zu komplex, um sie auf diese Weise zu steuern. Die Steuerung muss in kurzen Iterationen erfolgen, in denen vor allem der Kunde die Chance erhält, seine Anforderungen zu präzisieren oder sogar zu ändern.

So ist die Herausforderung, ein Brownfield-Projekt auf solide Füße zu stellen, oft mit der Notwendigkeit verbunden, den Prozess anzupassen beziehungsweise überhaupt einen definierten Prozess einzuführen. Das erleichtert die Aufgabe nicht gerade.