Was ist es nun, was ein Projekt nachhaltig erfolgreich macht oder nicht? Ein Projektleiter sagte einmal: "Eigentlich ist das ganz einfach. Man muss darauf achten, dass die Entwickler ihr Metier beherrschen und gut im Team zusammen arbeiten. Der Rest geschieht dann von selbst." Ohh… k., das mag stimmen, aber diese Konstellation ist nun mal nicht selbstständlich. Was geschieht, falls sich das Team nicht organisiert, falls mehr diskutiert wird als entwickelt, falls üble Düfte aus dem Code-Sumpf emporsteigen und die Entwickler beginnen, über das eigene Produkt schlecht zu reden? Spätestens dann muss das Management eingreifen, denn es ist davon auszugehen, dass die geplanten Entwicklungszeiten fortan um einen merklichen Faktor überschritten werden.

Häufig wird dann von Seiten der Entwickler das Management dafür verantwortlich gemacht mit all jenen unrealistischen Zeitvorgaben oder die Fachabteilung mit ihren unpräzisen Vorgaben und niemals endenden Änderungswünschen. Ja, auch das ist Realität. Allerdings liegen die Ursachen doch eher darin begründet, dass der Code gerade zu verrotten beginnt und es zunehmend anstrengender und aufwändiger wird, Änderung und Erweiterungen an ihm durchzuführen.

Nun steckt das Projekt in einer schwierigen Situation. Notwendige Umbauten (Refactorings) sind riskant, da i.d.R. keine ausreichende Testabdeckung existiert. Die meisten Projektleiter sehen jetzt nur noch eine Möglichkeit: Das Projekt mit aller Gewalt irgendwie zum Ende zu bringen. Dabei wird nun ausschließlich darauf geachtet, dass Tickets abgearbeitet werden. Jedwelche Qualitätsmerkmale außer den reinen funktionellen spielen nun keine Rolle mehr. Schlusslicht bei der Betrachtung bleibt die Code-Qualität, denn Dirty-Code lässt sich nun mal am besten verbergen.

Ich glaube, den meisten Projektverantwortlichen ist nicht bewusst, wie weit man in dieser Phase eh noch von einer wirklich brauchbaren Lösung entfernt ist! Dirty Code hat zudem die Eigenschaft, dass nicht selten die Behebung eines Tickets neue unerwartete Bugs an anderen Stellen sprießen lässt, was die finale Version weiter in die Ferne rückt.

Unsere Erfahrung zeigt, dass es sich in solch kritischen Phasen dennoch lohnt, noch einmal "die Säge zu schärfen", auch wenn dies initial einen zusätzlichen (z.T. nicht unerheblichen) Mehraufwand mit sich bringt. Der Schlüssel dazu liegt in der Einführung von CCD (Clean-Code-Development).

Wir betrachten das CCD nicht nur als eine Reihe von Coding-Regeln, wie der Name evtl. sugerieren mag, sondern lassen es auf drei Säule fußen:

1. der technischen,
2. der Tool-Säule und
3. der organisatorischen.

Die technische und zum Teil auch die Tool-Säule werden von der Literatur und der CCD-Bewegung bereits sehr ausführlich behandelt. Was uns stets die größeren Probleme bereitet, ist der organisatorische Teil: Wie lässt sich die Lehre in der Praxis umsetzen? Welche Maßnahmen und (Kontroll-) Prozesse sind sinnvoll? Ein erprobtes und erfolgsversprechendes Vorgehen aus unserer Praxis berichten wir in unserem Vortrag unter dem Namen Clean-Code-Controlling (s. Clean Code).

Im Anschluss an unseren Vortrag kam von der Zuhörerseite häufig die Frage: "Die Ideen haben mich überzeugt. Wenn unser Team nun bereit wäre, mit welchen Maßnahmen fangen wir denn nun als erstes an?";

Das ist eine berechtigte Frage, insbesondere inmitten laufender Projekte und bei eingespielten Teams. Hier bieten wir eine Lösung an: Das sog. Clean-Code-Startup-Kit. Wir planen demnächst eine Veröffentlichnug in einem bekannten Entwicklermagazin.

Wenn es soweit ist, können wir Sie gerne informieren (s. Netzwerke auf der Kontakt-Seite). Sprechen Sie mich an, falls Sie Interesse an einem Vortrag oder einer Schulung zu diesem Thema haben.