Qualität braucht Zeit
Wenn heutzutage eine neues Produkt auf den Markt gebracht werden soll, muss es oft sehr schnell gehen. Egal ob es sich um einen neuen Fernseher, ein neues Smartphone oder auch um neue Software geht. Bei Softwareanwendungen gibt es auch den schönen Begriff „Minimal Viable Product“ (MVP). Das bedeutet, dass zuerst ein minimaler Funktionsumfang der Softwareanwendung durch den Hersteller implementiert und dieses Produkt so den Kunden verkauft wird. Alle weiteren Funktionalitäten werden dann erst nach und nach per Update an den Kunden geliefert. Der Vorteil ist, dass das Produkt schnell am Markt verfügbar ist und die Kunden schnell die Grundfunktionalität erhalten. Ein Nachteil wiederum ist, dass zunächst auf viele zusätzliche Funktionen, Komfort oder Qualität verzichtet werden muss.
Eigentlich ein praktischer Ansatz. Doch was ist, wenn weitere Funktionalitäten durch den Kunden gewünscht werden, der Hersteller sich aber entscheidet, die eine oder andere Funktionalität gar nicht zu implementieren. Oder, wie die Realität oft zeigt, die Hersteller gar nicht ausreichende Kapazitäten haben, um viele wichtige Funktionalitäten in absehbarer Zeit zu bauen. Dann muss der Kunde damit leben, dass aus einer Basis-Softwareandwendung nie die tolle voll ausgebaute Softwareanwendung wird, die sich der Kunde eigentlich wünschen würde.
Die Ursache dieses Problems liegt oft im Ansatz des „Minimal Viable Product“ selbst. Damit es zu Beginn schnell geht, werden oft kleine agile Entwicklungsteams eingesetzt und viele grundlegende Funktionsbausteine der Software erst mal noch gar nicht implementiert. Sobald dann aber viel mehr Funktionen benötigt werden, können die kleinen Entwicklungsteams den manchmal exponentiellen Arbeitsaufwand nicht mehr bewältigen. Die Entwickler sind überlastet. Und wenn dann die Entwicklungsmanschaft personell aufgestockt wird, zieht das unweigerlich mehr Organisation und Management nach sich, was die durchschnittliche Entwicklungsgeschwindigkeit nicht unbedingt im gleichen Maße steigert.
Ein selten diskutierter, aber ebenfalls wichtiger Aspekt ist die nachträgliche Ergänzung von Funktionalitäten in der Software. Oft ist das gar nicht so einfach und schnell möglich, da die grundsätzliche Architektur dafür gar nicht ausgelegt ist. Und der Umbau der Architektur, um neue Funktionaltäten optimal zu unterstützen, scheitert vielleicht auch daran, dass personelle Ressourcen dafür nicht bereit gestellt werden können oder dass Entwickler nicht immer bereit sind umzudenken und bereits vorhandene Softwarearchitekturen nochmal komplett neu zu strukturieren. Die langfristigen Folgen von mangelndem „Refactoring“ sind oft zu beobachten: schlecht implementierte Funktionalitäten oder aus Architekturgründen überhaupt nicht realisierbare Funktionalitäten, höhere Anzahl an Fehler, längere Implementierungs- und Fehlerbehebungszeiten. Manche Software endet dann als der viel zitierte „Spagetti-Code“. Das Gegenteil von Qualität!
Zur Vermeidung dieser Situation ist man bei Unity Software einen anderen Weg gegangen. Es ging nie darum ein Produkt so schnell wie möglich auf den Markt zu bringen. Von Anfang an war die Qualität und ein großer Funktionsumfang verankert in einer idealen Softwarearchitektur das oberste Ziel. „Refactorings“ fanden und finden zu jedem Zeitpunkt statt. Wenn neue Funktionalitäten durch kreative Konzepte in die Softwareandwendung eingebaut werden können, ist es egal ob zusätzlicher Aufwand für den Umbau von grundlegenden Funktionen entsteht. Die Softwarearchiektur kann zu jeder Zeit adaptiert werden, durch alle Softwareschichten hindurch.
Und der Funktionsumfang bei den üblichen Grundfunktionen einer Anwendung ist heutzutage enorm. Egal ob beim Thema Loginmethoden, Sicherheitsimplementierungen, Einbindung von Dokumentarchiv, Bereitstellung von Webservice-Schnittstellen, Import- und Export von Daten, Hochverfügbarkeit der Anwendung, flexible Konfigurationsmöglichkeiten, Einbindung von lokalen Geräten (Drucker und Scanner), viele Geschäftsfunktionalitäten usw. Bei Unity Software wurden die Hausaufgaben gemacht. Nachträgliche Wünsche für die eine oder andere Funktionalität sollen beim Kunden gar nicht erst aufkommen müssen. Ein umfangreicher Funktionsumfang soll von Anfang an bereitstehen und dem Kunden Zeit und Kosten sparen, weil er sich darum keine Sorgen mehr machen muss.