27. May 2018

Die Herausforderung der Anpassbarkeit

Guten Morgen,

in der Softwareentwicklung wird zwischen Produkten und Projekten unterschieden. Die Unterscheidung ist folgende:1

  • Ein Produkt wird für den Markt entwickelt. Die Sofwarefirma investiert Geld in die Entwicklung eines Produktes mit dem Ziel, es einer großen Anzahl von Kunden zu verkaufen. Investieren meint in diesem Sinn Geld vorschießen, was vielleicht Gewinne bringt, wenn das Produkt fertig ist. Ein Produkt lockt daher mit gutem Gewinn (einmal Schreiben, häufig Verkaufen), birgt aber auch beträchtliche Risiken (der Markt interessiert sich nicht für das Produkt).
  • Ein Projekt wird für einen einzigen Kunden entsprechend seiner Bedürfnisse entwickelt. Üblicherweise muss die Softwarefirma auch hier das notwendige Budget für die Entwicklung vorlegen. Das Risiko ist aber deutlich geringer, da es mit Sicherheit einen Kunden gibt, der später die Entwicklungskosten der Software tragen wird. Der Gewinn ist andererseits aber auch niedriger, weil die Projektsoftware nicht an andere Kunden verkauft werden kann.

Viele Softwarefirmen haben Ihren Platz in der Mitte zwischen beiden Varianten gefunden: Sie bieten am Markt ein Standardprodukt an, schneiden dieses aber auch für die jeweiligen Kundenbedürfnisse zu. Dieses "Zuschneiden" wird üblicherweise Anpassung (oder dengl. Customizing) genannt - und ist eine der größten Herausforderungen beim Design eines Produkts.

In meinen Jahren als Softwareentwickler habe ich diverse Produkte angetroffen, die vielfach angepasst wurden. Und die meisten hatten mindestens eins der folgenden Probleme:

  • Alles ist private
    Dieser Umstand kann für einen Entwickler, der ein Produkt anpassen soll, extrem frustrierend sein. Das Produkt bietet nur wenige Einstiegspunkte, die nicht die benötigte Freiheit bieten. An jeder Ecke muss das Produktentwicklungs-Team gebeten werden, einen weiteren Einstiegspunkt zu definieren, oder noch eine Methode auf public umzustellen. Das kann ein zwei-Tage-Projekt schnell zu einer mehrwöchigen Odyssee machen.
  • Alles ist public
    Obwohl dieser Punkt das genaue Gegenteil des vorherigen ist, ist er kein Stück besser für eine Firma. Wenn irgendeine Methode public ist, wird sie jemand benutzen (und es vergessen). Eine öffentliche Schnittstelle kann niemals geändert werden, ohne die Sorge, dass eine Anpassung kaputt geht. Und wenn diese Anpassung wichtig war, kann aus einer kleinen Produktänderung ganz schnell ein politischer Alptraum werden. Das Resultat ist eine Sackgasse: wenn alles public ist, kann nichts mehr geändert werden. Die Produktentwicklung kommt zum Erliegen.
  • Die Produktarchitektur ist ein Chaos
    Eine chaotische Architektur ist schon für die Produktentwicklung schlimm genug. Ab einem gewissen Punkt, wird es immer schwieriger, eine schlechte Code-Basis zu verändern. Das Risiko, bestehende Funktionalität zu beschädigen, wird immer größer. Wie soll jemand eine komplexe kundenspezifische Funktion in eine solche Code-Basis einbauen, ohne etwas kaputt zu machen? Und wir soll man so eine Anpassung umsetzen, ohne dass sie noch schlechter wird als der bereits jetzt schlechte Code? Noch schlimmer: Kunden wollen manchmal Anpassungen auf Basis bestehender Anpassungen haben. Das ist wie ein schlechtes Essen mit miserabler Sauce und noch ekelhafterer Würzung.
  • Eine ausgezeichnete Vertriebsabteilung
    Einige Verkäufer können so ziemlich alles an den Mann bringen - und tun es auch.2 Und dass obwohl den Entwicklern die Haare zu Berge stehen, weil sie die Anforderungen kaum "hingebastelt" kriegen. Das resultiert häufig in Workarounds mit den seltsamsten Seiteneffekten.
  • Der "Produktaufkleber" wird auf Anpassungen geklebt
    Je nach Vertragswerk mit dem Kunden, kann eine Softwarefirma Anpassungen in das Produkt aufnehmen. Das ist super, wenn eine Anpassung wohlüberlegt als neue Funktion in das Produkt eingefügt wird. Wenn jedoch eine Anpassung nach der anderen einfach in das Produkt "reingeklatscht" wird, wird das Produkt nach einer Weile sehr wahrscheinlich chaotisch. Der Grund ist schnell erklärt: Eine Anpassung muss üblicherweise nicht alle Funktionen des Produkts berücksichtigen. Es ist klar, welche Funktionen der Kunde benötigt und einsetzt. Um die Kosten für die Anpassung niedrig zu halten, werden nur die notwendigen Änderungen gemacht. Warum sollte man eine Anpassung mit Funktion x kompatibel machen, wenn der Kunde diese Funktion gar nicht benutzt? Diese Anpassung einfach so in den Produktcode zu übernehmen führt aber zu einem Problem: Ein anderer Kunde wird die Funktion x sehr wohl verwenden, leider ist sie aber inkompatibel.

Viele dieser Herausforderungen können nur mit viel Selbstbeherrschung und guter Voraussicht angegangen werden. Allerdings gibt es verschiedene Wege den einzelnen Problemen zu begegnen:

  • Bei der Entwicklung eines neuen Produkts muss klar sein, ob die Software anpassbar sein muss, oder nicht. Im Zweifelsfall sollte die Antwort ja lauten.3
  • Jede Software muss eine klare Architektur haben. Dies gilt besonders, wenn andere die Software erweitern können sollen. Ich persönlich bin der Meinung, dass die genaue Ausprägung der Architektur nicht so wichtig ist, wie die konsistente Einhaltung dieser Architektur. Wenn ein neues Team-Mitglied (egal ob in der Produkt- oder Projektentwicklung) einen Teil der Anwendung verstanden hat, sollte dieses Wissen auf alle anderen Teile der Software übertragbar sein.
  • Überlegen Sie die Implementierung eines Plugin-Systems Plugins sind ein mächtiges Werkzeug für Anpassbarkeit. Im Extremfall kann die gesamte Funktionalität eines Produkts in mehrere Schichten von Plugins gepackt sein, womit alles für den Kunden angepasst werden kann (allerdings wird die Architektur dann schwieriger zu verstehen).
  • Verwenden Sie automatisierte (Regressions-)Tests. Automatisiertes Testen hilft nicht nur bei der Entwicklung des Produkts oder der spezifischen Anpassung. Der tatsächliche Nutzen wird erst ersichtlich, wenn automatisierte Regressionstests auf einmal für das Produkt und alle seine Anpassungen durchgeführt werden können. Immer wenn die Produktentwicklung (mal wieder) die Schnittstelle kaputt gemacht hat, wird der Fehler durch automatisierte Tests gefunden, bevor die Änderung zum Kunden ausgerollt wird. Das verhilft dem Produktentwickler, wie auch dem Projektentwickler zu ruhigeren Nächten, weil beide ziemlich sicher sein können, dass ihr Zeug auch am nächsten Tag noch funktioniert.
  • Während der Umsetzung der Anpassung sollten Produkt-Features, die nicht kompatibel sein werden, berücksichtigt und dokumentiert4 werden. Sollte später jemand die Anpassung in das Produkt übernehmen, ist die Chance damit höher, dass inkompatible Funktionen entdeckt werden.
  • Es sollte nicht alles public/private gemacht werden. Für jeden Teil der Anwendung muss bedacht werden, ob Anpassbarkeit notwendig ist oder nicht. Alles was anpassbar sein soll, muss eine klare öffentliche Schnittstelle (im Grunde eine API) besitzen. Diese Schnittstelle muss derart gestaltet sein, dass a) sämtliche notwendige Funktionalität vorhanden ist und b) die Schnittstelle um Funktionalität erweitert werden kann, die wir in a) vergessen haben.5 Wenn die Produktentwicklung sich unsicher ist, welche Teile der Schnittstelle öffentlich sein müssen, sollte gewartet werden, bis die erstem Anpassungen umgesetzt werden. Meiner Erfahrung nach ist es besser zu viel private statt public zu machen. Allerdings muss es einen einfachen Weg für Projektentwickler geben, die benötigte öffentliche Schnittstelle zu erhalten, wenn sie gebraucht wird. Das führt mich zum nächsten und wichtigsten Punkt:
  • Reden Sie mit Ihren Kollegen (Kaffeemaschine sind super dafür). Meiner Erfahrung nach, gibt es häufig Mauern6 zwischen Produktentwicklung und Projektentwicklung. Insbesondere wenn es sich dabei um unterschiedliche Abteilungen handelt. Allerdings wissen nur die Mitarbeiter der Customizing-Abteilung, was sie wirklich brauchen.

Meiner Meinung nach ist Anpassbarkeit eine riesige Herausforderung. Customizing ist eine der größten Einnahmequellen vieler Software-Unternehmen, aber es gibt keinen einen Weg, sie korrekt umzusetzen. Trotzdem hoffe ich, hier einige Denkanstöße gegeben zu haben, die die Arbeit von Produkt- und Projektentwicklung gleichermaßen verbessern.

  1. Das ist natürlich eine vereinfachte Unterscheidung. Wie üblich gibt es in der Realität viele Übergänge zwischen Produkt und Projekt. Eine Softwarefirma könnte bspw. eine Anpassung vergünstigt anbieten, dafür aber die Erlaubnis vom Kunden einholen, die Anpassung auch anderen Kunden zu verkaufen.
  2. Diese Anmerkung sollte nicht zu ernst genommen werden. Wie so oft, sind weder der Verkäufer, noch die Softwareentwicklung hier "schuld". Es gibt aber Anpassungen, die besser nicht gemacht worden wären. Und bessere Kommunikation zwischen den Abteilungen kann Wunder bewirken, um solche Missstände zu vermeiden.
  3. Zugelassene Antworten sind: ja und vielleicht.
    4 Diese Dokumentation könnte sogar in Form eines Tests abgebildet werden: Wenn Funktion x aktiv ist, schlägt der Test mit einer passenden Fehlermeldung fehl.
  4. Meines Erachtens nach ist das eine der größten Schwierigkeiten. Eine gute Lösung für dieses Problem ist eine Kombination aus Plugin-System und Dependency Injection. Plugins kriegen ihre Abhängigkeiten übergeben, die wiederum eine leicht zu erweiternde öffentliche Schnittstelle haben. Allerdings kann man mit diesem Thema Bücher füllen, es kann hier also nicht vollständig behandelt werden.
  5. Die Größe dieser Mauer kann von Gartenzaun bis zu Chinesischer Mauer reichen. Nur offene Kommunikation kann zu guter Software führen. Insbesondere wenn die Software noch nicht am Markt etabliert ist.