Projektmanagement Softwareentwicklung

Softwareentwicklung für Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Software-Design: Designdemokratie? – Nein danke!

    Jörg Hinrichs

    Ich bin sehr froh, in einer Demokratie zu leben. Ich finde das ist eine der besseren Staatsformen. Aber im Design von Software hat Demokratie meiner Meinung nach keinen Platz. Da sind eher Diktatoren gefragt!

    Um keine Missverständnisse aufkommen zu lassen: Ich rede hier über High-Level Software-Design. Damit meine ich:

    • Das Schichtenmodell einer Anwendung.
    • Interfaces, mit denen die jeweiligen Schichten miteinander kommunizieren.
    • Übergreifende Funktionalitäten wie beispielsweise Persistenz von Informationen, Validierung von Eingaben, Implementierung von Business-Regeln etc.

    Es geht also um den generellen Aufbau einer Anwendung, nicht um einzelne Details der Implementierung.

    Design-Erkenntnisse: Was ist eigentlich das Problem?

    Ich halte es für sehr wichtig, dass die grundlegenden Komponenten und Funktionen einer Software ein einheitliches Design besitzen. Aber stellen wir das ruhig für den Moment in Frage: Was ist eigentlich so schlimm daran, wenn das Design nicht einheitlich ist?

    Ich habe selbst eine Software mitentwickelt, die mindestens drei grundlegend verschiedene Design-Ansätze in sich vereinigt. Ist das ein Problem? Ok, neue Entwickler haben es natürlich etwas schwerer, sich zurechtzufinden. Aber seien wir mal ehrlich: Das verzögert die Einarbeitungszeit ein wenig, ist aber kein wirklich grundlegendes Problem.

    Die größte Schwierigkeit für mich liegt darin, dass ein uneinheitliches Design dazu tendiert, vermehrt Abhängigkeiten zwischen den einzelnen Bestandteilen einer Software zu produzieren. Am Anfang ist das gar nicht so schlimm. Aber mit der Zeit wird das zu einem immer größeren Problem.

    Ich könnte auf Anhieb drei Projekte nennen, in denen aufgrund von Abhängigkeiten regelmäßig zentrale Bestandteile einer Anwendung nicht mehr modifiziert werden (oder nur noch wenn man es gar nicht mehr vermeiden kann). Stattdessen wird um diese Bestandteile “herumprogrammiert”. Die größte Hürde liegt dabei gar nicht unbedingt im Programmieren selbst, sondern im anschließenden Testen. Das ist aufgrund der vielen Abhängigkeiten sehr aufwendig und umfasst häufig auch Teile der Anwendung, die mit dem ursprünglichen Feature oder Change Request nicht direkt etwas zu tun haben. Man nimmt also bewusst ein suboptimales Design in Kauf, weil man ein besseres Design schlecht verkaufen kann.

    Design-Vielfalt: Wenn das Kind schon in den Brunnen gefallen ist…

    Nehmen wir einmal an, Ihre Software-Anwendung hat bereits ein uneinheitliches Design. Was können Sie tun?

    Wenn es sich um ein größeres Release handelt oder wenn die Anwendung gerade neu erstellt wird, dann können Sie versuchen, eine Refactoring-Phase durchzuführen. Moderne agile Entwicklungsprozesse sehen das ohnehin standardmäßig vor. Es wird nicht ganz einfach sein, denn aufgrund der vielen Abhängigkeiten werden Sie entsprechend viele Module der Anwendung “anfassen” müssen (je nachdem, wie groß diese Abhängigkeiten bereits sind). Vielleicht müssen Sie beim Refactoring sehr strukturiert vorgehen, um nicht irgendwann komplett den Überblick zu verlieren. Gerade bei größeren Restrukturierungen will das gut geplant und diszipliniert durchgeführt sein. Dennoch, in dieser Situation kann man eine oder mehrere Wochen für Refactoring noch am ehesten verschmerzen, weil die gesamte Entwicklungsdauer wesentlich größer ist.

    Wesentlich schwieriger ist es, wenn die Anwendung bereits läuft und nur noch hier und da ein neues Feature dazukommt oder eine kleine Verbesserung bestehender Funktionalität erfolgt. In so einem Fall aus Design-Gründen eine gravierende Änderung vorzunehmen, ist sehr schwierig. Meistens werden Sie nämlich Leute überzeugen müssen, die von Softwareentwicklung keine Ahnung haben und auch nicht einschätzen können, wie viel Zeit ein schlechtes Design kosten kann. “Ist das denn wirklich notwendig? Es läuft doch!”, hat wohl jeder Softwareentwickler schon mal gehört.

    Es ist ja auch nicht nur die Entwicklung, die bezahlt werden muss, sondern es werden auch zusätzliche Ressourcen beansprucht. Insbesondere kann es schwierig werden, Tester für den Abnahmetest bereitzustellen, wenn für den Kunden (bzw. Endanwender) kein unmittelbarer Nutzen ersichtlich ist. Dementsprechend groß ist dann auch die Versuchung, Designüberlegungen erst einmal zu ignorieren und die nächste Notlösung zu basteln (wohl wissend, dass die Hürde für ein Redesign damit jedes Mal ein Stückchen höher wird).

    Design-Änderungen: Never change a running system!

    Nehmen wir einmal an, es gibt bereits ein fertiges Software-Design und größere Teile der Anwendung sind schon damit implementiert worden. Mittlerweile haben sich jedoch Schwächen des Designs offenbart, und Sie möchten es gerne ändern.

    Ein bestehendes Software-Design sollte niemals leichtfertig geändert werden, denn Sie nehmen eine Menge Unannehmlichkeiten in Kauf. Meistens sind die Änderungen so grundlegend, dass die gesamte Anwendung (mehr oder weniger) davon betroffen ist. Der daraus resultierende Aufwand bezüglich Implementierung und Test ist nicht zu vernachlässigen. Sie müssen also schon ziemlich gute Gründe haben, um ein Design zu ändern.

    Wenn Sie sich dennoch zu einer Änderung des Designs entschlossen haben, dann machen Sie es nach Möglichkeit in einem durchgehenden Schritt. Oft wird versucht, aus Zeitgründen Kompromisse zu machen:
    “Wir implementieren das neue Design bei jedem Programmmodul, welches wir im Rahmen einer Änderung oder eines neuen Features anfassen müssen. Auf diese Weise ersetzt das neue Design Schritt für Schritt das alte, und wir verlieren nicht so viel Zeit.”
    Genau diesen Versuch habe ich schon ein paar Mal erlebt und es ist jedes Mal beim Versuch geblieben. Am Ende gab es dann immer noch ein paar hartnäckige Restbestände des alten Designs.

    Planen Sie die Umstellung deshalb auch als solche in die Terminplanung mit auf. Natürlich ist es ärgerlich, dass sich andere Aktivitäten dadurch verschieben, aber ein einheitliches Design ist an dieser Stelle wichtiger (sonst hätten Sie diese Umstellung gar nicht erst in Angriff genommen).

    Design-Demokratie? – Nein danke!

    Ich habe es zu Beginn bereits erwähnt: Ich bin der Überzeugung, dass ein Software-Design immer von einer einzigen Person entworfen werden sollte.

    Wenn ich in diesem Zusammenhang von einer Diktatur rede, hört sich das immer so martialisch an. Das heißt aber nicht, dass es keine Diskussionen über das Design geben darf. Im Gegenteil: Viele Köpfe haben viele Ideen, und die sollen sie auch ruhig kundtun.

    Aber: Die Entscheidung, was am Ende umgesetzt wird, sollte nur eine Person treffen (ich nenne sie mal den Architekten). Wenn der Architekt eine Idee gut findet, nimmt er sie in das Design auf. Wenn nicht, dann nicht. Wenn diese Verantwortung im Vorfeld klar kommuniziert wurde und von den anderen Entwicklern anerkannt wird, dann ist hier nicht mit größeren Problemen zu rechnen (auch wenn vielleicht nicht immer alle mit einer Entscheidung einverstanden sind).

    Vielleicht ist es nicht immer das beste Design, welches dadurch entsteht. Manchmal gibt es auch verschiedene Ansätze, die beide ihre Vor- und Nachteile haben und wo man sich einfach nur entscheiden muss, wo man Prioritäten setzen möchte. Für mich ist aber ein einheitliches Design mit kleineren Fehlern in jedem Fall besser als ein Mix aus verschiedenen Ansätzen. Selbst wenn die im Einzelfall gut begründet werden können.

    Ich erinnere mich auch an diverse Design-Diskussionen, in denen versucht wurde, alle Beteiligten von der Überlegenheit eines bestimmten Ansatzes zu überzeugen. Manchmal identifiziert sich ein Entwickler so sehr mit “seiner” Idee, dass er jegliche Kritik automatisch als Kritik an sich selbst auffasst. An dieser Stelle wird es sehr schwer, objektiv über Inhalte zu sprechen.
    Solche Diskussionen sind zäh und bringen viel soziale Unruhe ins Team. Fast immer gibt es keinen oder nur einen quälend langsamen inhaltlichen Fortschritt. Und sie tendieren dazu, regelmäßig wieder aufzuflammen, auch wenn bereits entsprechende Entscheidungen getroffen wurden.

    Dann doch lieber eine einzelne Person, die sich alle Meinungen anhört und dann zügig und kompetent eine Entscheidung trifft. Mit dieser Entscheidung muss nicht jeder konform gehen – Hauptsache sie wird akzeptiert.

    Design-Vorgaben: Das Application-Template

    Bei vielen Anwendungen verschlechtert sich im Verlauf ihres Lebenszyklus das Design. Agile Entwicklungsprozesse haben diese Problematik erkannt und bauen deshalb nach Bedarf Refactoring-Phasen ein, in denen lediglich eine Verbesserung des Designs stattfindet, ohne dass neue Funktionalität implementiert wird. Das ist in jedem Fall ein Fortschritt, weil meistens schon sehr frühzeitig Probleme beseitigt werden statt zu warten bis sie so groß sind, dass es wirklich weh tut.

    Ich gehe aber noch einen Schritt weiter: Noch besser wäre es, von vornherein ein Design-Gerüst vorzugeben, welches für grundlegende Änderungen gar keinen Spielraum mehr lässt und damit ein Design erzwingt, welches im Verlauf der Entwicklung nicht mehr schlechter wird. Diesen Ansatz nenne ich “Application-Template”. Ich werde ihn demnächst in einem weiteren Artikel detailliert vorstellen.

    Zusammenfassung

    Hier noch einmal die wichtigsten Gedanken und Richtlinien aus diesem Artikel:

    • Design-Diktatur
      Grundlegende Designentscheidungen sollten nur von einer Person getroffen werden.
    • Design-Vielfalt vermeiden
      Parallel nebeneinander existierende Designs erzeugen vermehrt Abhängigkeiten und sind unbedingt zu vermeiden.
    • Ändern Sie ein Design nur, wenn Sie dafür sehr gute Gründe haben.
    • Wenn Sie ein Design umstellen, tun Sie es in einem Schritt.
    1 Comment

One Response to “Software-Design: Designdemokratie? – Nein danke!”

  1. [...] Software-Design: Designdemokratie? – Nein danke! [...]

Leave a Reply