In Fowlers Blog habe ich jetzt einen Verweis auf ein Video von Ward Cunnigham gefunden, in welchem er den Begriff Technische Schulden erläutert und in 4 Minuten und 44 Sekunden auf den Punkt bringt.

Feature-Suppe nennt Tom DeMarco das von mir beschriebene Phänomen, wenn einer Software unkontrolliert und nur auf kurzfristigen Nutzen hin ausgerichtet neuen Funktionalitäten hinzugefügt werden. Als Grund hierfür sieht er das Fehlen einer Person, die das große Ganze im Auge hat und unter diesem Aspekt die Entwicklung koordiniert. Nachzulesen ist dieses Anti-Pattern in
Adrenalin-Junkies und Formular-Zombies - Typisches Verhalten in Projekten
.
Technical Debt lautet die Bezeichnung hierfür bei Martin Fowler die Bezeichnung. Im Unterschied zu Tom DeMarco liegt sein Fokus aber auf den technischen Problemen die sich aus kurzsichtigen Umsetzungsstrategien ergeben. Schnell hinzugehackte Funktionalitäten ala „Chef, in drei Stunden ist das fertig! Dafür muß ich nur hier noch kurz …“ freuen zwar manchen und sind sogar manchmal möglich, doch in der Regel werden bei so sogenannte technische Schulden angehäuft, die irgendwann samt Zinsen wieder abgezahlt werden müssen und zwar dann, wenn all die Schnellschüsse in eine saubere und wartbare Architektur oder Konzept überführt werden müssen.

Ein gutes Beispiel hierfür ist Event Driven Software Development. Als Abkürzung ist EDSD etwas sperrig, ausgesprochen klingt es nach Dynamik und Aktivität, und strotzt nur so vor Energie. Vom Namen her hat Event Driven Software Development her also die absolute Chance zum neuen Shotting-Star der Software-Entwicklung aufzusteigen.

Wir alle wissen, daß sich die Anforderungen an unsere Software schon recht früh ändern können und die Änderungswünsche nicht nur von außen, sondern auch innen, direkt aus dem Team kommen. Im Idealfall erkennen wir Dinge, die anders, besser und effizienter erledigt werden können oder es wird schnell mal eine Funktion eingebaut, die die Sonderkonstellation 4711 wunderbar abdeckt. Dann kommen noch anderen Abteilungen auf uns zu, die für die eine Veranstaltung oder jeden Kunden eine bestimmte Funktion brauchen. Wir als Softwareentwickler verstehen uns natürlich als Dienstleister nach innen und außen und bemühen uns allen gerecht zu werden und jeden Wunsch so gut wie möglich umzusetzen. All dies bezeichne ich als Events auf die wir bei der Entwicklung reagieren müssen und die sich als Change Request auf die Entwicklungsziele auswirken können.

Unsere Aufgabe ist es diese Events zu steuern und ihre potentielen Auswirkungen einzuschätzen und sie zu managen. Je weiter ein Projekt voranschreitet, desto geringer sollten die Änderungen an ihm werden, da wir sonst unser Ziel nicht erreichen können oder es zumindest gefährden. Also ist die Zeit ein wichtiges Kriterium bei der Behandlung von externen Ereignissen, die zu Änderungsanforderungen führen können. Bis hierher wird es sicherlich keinen Widerspruch geben.

Aber kann jede Änderung, die nicht hinsichtlich Zeit unkritisch ist, auch umgesetzt werden? Nein lautet hier die Antwort. Jede Änderung muß auch danach beurteilt werden, wie gut sie sich in das Produkt, also die Software, einfügt und auch zu den Zielen, die erreicht werden sollen, beiträgt.

Letztendlich zeichnen sich gute Produkte auch durch Konsistenz aus. Konsistenz stellt daher auch ein Qualitätsmerkmal dar, daß es im Auge zu behalten gilt. Denn die wirklich guten Produkte sind in sich konsistent.

Bei jeder Änderung muß also auch kritisch gefragt werden:

1. Trägt diese Änderung zum (strategischen) Projektziel bei?
2. Fügt sich diese Änderung harmonisch in das Produkt ein?
3. Kann das durch die Änderung angestrebte Ziel auch anders erreicht werden?
4. Ist jetzt der richtige Zeitpunkt für diese Änderung?
5. Gibt es andere Änderungsanforderungen, die den gleichen Gegenstand haben und zusammen umzusetzen sind oder sich ausschließen?

Diese Fragen müssen jedesmal gestellt und beantwortet werden. Falls diese Fragen zu keinem positiven Ergebniss führen, sollte die Änderung hintenangestellt werden, denn ansonsten sind wir nur am Hin-Und-Her-Springen und verlieren Zeit und Qualität. Diese Punkte, scheint mir, werden zu oft vergessen, denn kurzzeitiges Denken siegt oft über langfristigen Erfolg. Denn die Rechnung kommt erst später, denn je später eine notwendige Korrektur erfolgt, desto teurer ist sie.

Event Driven Software Entwicklung ist also ein Anti-Muster und verweist auf eine schwache Steuerung innerhalb eines Projekts und sollte die Frage nach der Projekt oder Firmenkultur aufwerfen.

Meine These lautet: Gute Software ist eine notwendige Voraussetzung für langfristigen Erfolg.

Richtig ist aber auch, daß gute Software ein notwendiger Grund für Erfolg ist, aber kein hinreichender. Nur aufgrund guter Software stellt sich kein Erfolg ein, aber es wird leichter erfolgreich zu sein.