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.

Josuttis schreibt darin über einem Vortrag auf der Agile 2008 zum Thema Software-Qualität, der von Robert C. Martin gehalten wurde. Martin stellt fest, daß wir in der Software-Branche zu viel Mist produzieren. Vorallen tun wir das, weil einfach zu wenig Zeit dafür zur Verfügung steht um sauber zu arbeiten zwischen all den Budgetplänen, Tagessätzen und Releaseterminen. Insofern ist das Sujet bekannt und die meisten von uns können das wohl aus der einen oder anderen Erfahrung bestätigen.

Das eigentlich interessante ist, daß Josuttis das wohl aus eigener Erfahrung kennt und auch darlegt, wie er versucht diesem Problem beizukommen und damit glatt die nächste Revolution in der IT-Welt vorhersagt.

Josuttis versucht dem Problem beizukommen, in dem die Entwicklung von Fachlichkeiten vom „Sauermachen“ trennt. Es gibt also zwei Gruppen. Die einen schreiben fleißig Code und die anderen bringen ihn in Ordnung. Schlechter Code ist demnach in Ordnung, da er später glattgezogen wird. An die großen Hypes Agilität und SOA anknüpfend entwickelt er diesen Gedanken weiter und stellt die Frage, warum wir nicht endlich schlechten Code akzeptieren, schließlich haben wir mit der Agilität sich wandelnde Anforderungen akzeptiert und sogar kultiviert und SOA das gleich mit heterogenen Systemen getan. Schlußendlich sollten wir aufhören, schlechten Code zu bekämpfen, sondern sinnvoll damit umgehen.
So sehr er mit vielem auch Recht hat, umso mehr irrt er hier doch und kommt zu einem falschen Schluß. Schlechter Code ist zu bekämpfen.

Eine allgemein gültige Definition von gutem Code gibt es nicht. Daher für aber viele von Qualität. Mir gefällt am besten die DIN-Definition, wonach Qualität „die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse (Qualitätsanforderungen) zu erfüllen“ ist. Zugegebener Maßen klingt das etwas sperrig und erschließt sich nicht direkt, denn was sind „abgeleitete Erfordernisse“. Qualität hat viele Ausprägungen, wie da wären:

• Funktionalität
• Zweckdienlichkeit
• Sicher
• Robustheit
• Benutzbarkeit
• Zuverlässigkeit
• Änderbarkeit
• Portierbarkeit
• Prüfbarkeit
• Geschwindigkeit

Jeder wird zugeben, daß eine Software, die nicht die geforderten Funktionen bringt aus Kundensicht nichts wert ist. Insofern ist Funktionalität ein hinreichendes Qualitätsmerkmal, aber allein nicht ausreichend. Je länger eine Software lebt, umso wichtiger werden auch Merkmale wie Wartbarkeit und Änderbarkeit und können zum Schluß mehr über den Erfolg Ihrer Software entscheiden als die eigentliche Funktionalität.

Natürlich muß man am Code verzweifeln, wenn man die perfekte Architektur und eine konsistente Einhalt von Codierrichtlinien erwartet und hofft, daß alle Entwickler den gleichen Stil pflegen und sich mit der gleichen Hingabe ihrer Aufgabe widmen. Die Welt ist nicht perfekt und wir sind es nicht, warum sollte es unsere Software sein? Perfekte Software ist schlichtweg unmöglich. Sie ist unmöglich, weil sich die Welt rund um die Software ständig ändert. So ändern sich die Anforderungen, im Idealfall werden sie konkreter und damit für alle besser. Wir wissen besser, was unser Kunde will und der Kunde erhält eher das, was er braucht. So ändern sich die Tools mit denen wir arbeiten. Werden sie besser, so verbessert sich unser Stil Software zu entwickeln - oder wirft uns um Jahre zurück. So ändern auch wir uns. Mit jedem Projekt wächst unser Wissen und Können, auch wenn wir uns ehrlicher Weise auch bei ählichen Fehlern immer wieder selber stellen. Das war wir gestern geschrieben haben, ist uns Wissen, Können und Vermögen von gestern und das kann das Beste gewesen sein, was wir zu diesem Zeitpunkt leisten konnten.
Allerdings ist das alles kein Grund schlechte Software zu akzeptieren. Oder möchten Sie schlechte Software benutzen. Jeder von uns erwartet, daß der Geldautomat zu jeder Tageszeit funktioniert und nicht irgendwie, sondern richtig. Und freut sich, wenn das zu übernehmende Projekt gut geführt und die Sofware sauber implementiert ist.

Vielmehr sollten wir uns umso mehr bemühen gute Software mit perfekten Code zu entwicklen. Wie schon weiter oben geschrieben ist das Ziel nicht erreichbar, doch wenn wir es uns als Ziel setzen werden die Ergebnisse weit besser sein, als wenn wir uns von vornherein nur mit Mittelmäßigkeit begnügen. Denn sobald wir dies verinnerlicht haben, werden wir uns mit noch weniger zufrieden geben.

Dieser Witz ist mir bei der Lektüre von „Adrenalin Junkies und Formular Zombies“ von Tom DeMarco und Co eingefallen, als ich mich gefragt habe, welche Verhaltensmuster ich selber kenne, die aufgeschrieben werden sollten.

Leberwurststullen gibt es dann, wenn die Entwickler in einer Firma niemals mit dem eigenen Produkt arbeiten würden und sich wundern, daß andere es tun. Ein Beispiel hierfür war mein rumänischer Kollege Florian, der sich immer geweigert hatte Online-Banking-Systeme zu benutzen. Auf unsere Nachfrage wieso meinte er nur, daß er in einem Team zur Entwicklung von Online-Banking-Systemen gewesen wäre und wüßte wie diese geschrieben würden. So etwas macht einen dann immer sprachlos. Nach Leberwurst riecht es auch, wenn ein Team mit einer selbstentwickelten Software arbeitet, die es selber für schlecht und unausgereift hält, es aber für Kundenprojekte einsetzt.

Diese beiden Varianten haben den gleichen Ursprung, wenn auch unterschiedliche Auswirkungen. In beiden Fällen haben alle Beteiligten das bewußte oder unbewußte Gefühl, daß etwas mit der Software die entwickelt wird oder dem Softwareentwicklungsprozess nicht stimmt. Daher können sie kein inneres Vertrauen zu ihrem Produkt entwickeln, nutzen es selber nicht und es bildet sich teilweise eine leicht zynische Haltung gegenüber dem Produkt. Das ist vergleichbar mit Bankern, die bei vollem Bewußtsein Kredite an nicht zahlungsfähige Häuslebauer vergeben und uns so die aktuelle Finanzkrise beschert haben.

In unserem Falle sind aber nicht die Entwickler daran schuld. Vielmehr fehlen in solchen Firmen zwei Dinge: Zum einen eine offene Kultur der konstruktiven Kritik und zum anderen ein Bewußtsein für Qualität. Eigentlich schade, den Qualität ist eigentlich gar nicht so teuer, denn auch wenn immer mit Aufwänden argumentiert wird, entsteht Qualität in aller erster Linie durch den Willen dazu.