Software Engineering Blog

Alles braucht einen Namen und was wir nicht benennen können ist schwer bis gar nicht in unserer Begriffswelt unterzubringen und es fiele auch ziemlich schwer über diese Dinge zu sprechen, die wir nicht benennen können. All das, dem wir einen Namen geben können existiert und wir können es zum Gegenstand unserer Betrachtungen machen.

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.

Regelmäßig lese ich „The World of IT“ und „Bernds Management Blog“ auf den Seiten der iX, die von OOSE-Chef Bernd Österreich, Jutta Eckstein und Nicolai Josuttis geschrieben werden. Mit durchschnittlich einer Veröffentlichung pro Monat ist es auch ein leichtes jede Veröffentlichung zu lesen. Falls Sie auch diese Blogs lesen: Ist Ihnen schon einmal aufgefallen, daß jeder der genannten eine für eine bestimmte Grundhaltung steht? An welche ich dabei denke will ich heute für mich behalten, besonders da ich mich mit dem letzten Beitrag von Nicolai Josuttis auseinander setzen möchte.
(weiterlesen...)

Zu DDR-Zeiten gab es folgenden Witz: Zwei Schüler sind auf dem Schulhof. Der eine öffnet seine Tasche, nimmt seine Stullen raus und wirft sie weg. Worauf der andere fragt: „Warum wirfst du sie weg, du weißt ja noch gar nicht, was drauf ist.“ Der erste Schüler antwortet: „Leberwurst. Ich habe sie ja selber gemacht.“

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.