“Das MVP von heute ist die Legacy-Software von morgen” – Richard Seidl
Also, es gibt schon mehrere. Aber eines sticht immer wieder heraus. Ich arbeite viel mit größeren Unternehmen, die schon lange Software entwickeln und wenn ich so in die System- und Applikationslandschaft schaue, ist da eine unfassbare Komplexität an Fachlichkeit und Technik entstanden. Und immer wird noch was Weiteres angebaut, “weil man es braucht”. Ich stelle mir dann manchmal die Frage, was das alles kostet.
Der Overhead, in diese komplexen Strukturen noch irgendeine Fachlichkeit einzubauen: Lohnt sich das denn überhaupt? Also gibt es da irgendwann einen ROI? Beantworten kann das niemand mehr, dafür sind die Kosten- und Aufwandsströme viel zu undurchsichtig. Aber: Diese Unternehmen verdienen ja trotzdem noch Geld, sonst würden sie nicht mehr existieren. Das ist in meinem Kopf nur schwer zusammenzubekommen. Aber wie entsteht so ein Ungetüm an Software über Jahrzehnte? Vorweg: Das ist keine Frage der Technologie, solche Softwaremonster gibt es nicht nur mit Host-Systemen, auch mit Microservices.
Neigungen
Der Mensch unterliegt im Leben gewissen Neigungen und Vorurteilen. Der englische Begriff dafür ist Bias – ich habe noch keinen passenden deutschen dazu gefunden. Ein Klassiker: der Confirmation Bias. Wir neigen dazu, Informationen zu suchen und zu interpretieren, die unsere vorherigen Annahmen und Hypothesen bestätigen. Oder der Affinity Bias. Wir finden Menschen, die uns ähnlich sind oder ähnliche Vorlieben haben, sympathisch. Die Liste ist noch lang. Nicht zu vergessen, diese Bias hatten und haben auch immer ihren Sinn im Leben beziehungsweise der Evolution.
Lösungsstrategien
Relativ jung ist die Forschung rund um den Additive Bias. Dieser besagt – und wurde mit Studien unterlegt –, dass wir für eine Problemlösung lieber etwas hinzufügen, als etwas wegnehmen. Auch wenn das “Wegnehmen” die bessere, günstigere, Lösung wäre. Und das ist ja schon in der Schule so. Addieren ist für die meisten Menschen einfacher als Subtrahieren. Der Grund könnte ganz einfach sein: Der kognitive Aufwand beim Hinzufügen ist kleiner als beim Wegnehmen. Also einfach: Gehirn-Energiesparen.
Als ich mich das erste Mal damit beschäftigt habe, hat es mich wie einen Blitz getroffen. Wir machen in der Softwareentwicklung ja nix anders und das auf mehreren Ebenen:
- Fachlichkeiten werden ergänzt, anstatt bestehende anzupassen oder zu entfernen. Es könnte ja noch jemand brauchen. Oder man müsste viel Impact analysieren. Wer weiß, ob dann noch alles funktioniert.
- Auch in der Softwareentwicklung: Ist der Code komplex, die Architektur so lala und die Unittests mehr Schein als Sein, dann wird lieber noch ein if dazu gebaut, anstatt die Funktion einem Refactoring zu unterziehen.
- Und im Testing ebenso: Testfälle löschen? Fehlanzeige. Lieber noch einen extra dazu. Wir haben ja so viel Energie reingesteckt. Aber ob die 1000 automatisierten Testfälle überhaupt Fehler finden? Nun ja.
Und schwuppdiwupp sind sie da: die technischen Schulden, die Komplexität. Oder weg: die Wartbarkeit, die Testbarkeit, die Übersichtlichkeit.
Feature Fatigue
Aber nicht nur die Softwareprojekte haben damit ein Problem. Ebenso der Nutzer. Feature Fatigue beschreibt die Unzufriedenheit, Frustration und Überforderung der Nutzer durch zu viele und unklare Features.
Als Consumer kann ich da vielleicht noch schnell die App wechseln. Aber für Anwender von Business-Software schaut es schon schwieriger aus. Ein Sachbearbeiter muss das nutzen, was er vorgesetzt bekommt. Ob er will oder nicht. Freude und Zufriedenheit mit dem Tool sind egal.
Eine neue Qualität
Für mich als Coach für Dev-Teams ist das ein ganz spannender Aspekt von Softwarequalität: Was kann ich weglassen? Von den Qualitätskriterien kann ich es vielerorts unterbringen: Einfachheit, Bedienbarkeit, Wartbarkeit, Usability, User Experience, Testbarkeit usw. Ich kenne kaum Unternehmen, die sich dieses Themas ernsthaft annehmen. Hochtrabend konnte man das teilweise bei Apple beobachten (alte Zöpfe abschneiden), aber auch dort werden iPhones mit jeder Generation überladener.
Ich denke: Bewusstheit ist der erste Schritt. Und dann mal ran ans Ausmisten – denn weniger ist oft mehr.
PS: Ich habe vor ein paar Wochen eine Ausmist-Challenge gemacht und rund 700 Items aus dem Haushalt entfernt, plus viele digitale Artefakte. Ergebnis: Eine Wohltat wieder mehr Raum zu haben. Ob uns das in der Software auch gelingt?
Häufig gestellte Fragen
Warum wächst gewachsene Unternehmenssoftware über Jahrzehnte zu einem unbeherrschbaren Gebilde?
Weil laufend etwas angebaut wird, “weil man es braucht”, ohne dass jemand die Kosten dagegenrechnen kann. In großen Firmen entsteht so eine kaum noch überschaubare Menge an Fachlichkeit und Technik. Ob sich der Overhead, in diese Strukturen noch eine weitere Funktion einzubauen, überhaupt amortisiert, lässt sich nicht mehr beantworten: Die Kosten- und Aufwandsströme sind zu undurchsichtig.
Verhindert eine moderne Architektur wie Microservices, dass Software zum Monster wird?
Nein. Softwaremonster sind keine Frage der Technologie. Sie entstehen mit Host-Systemen genauso wie mit Microservices. Ausschlaggebend ist die Gewohnheit, Probleme durch Hinzufügen zu lösen: neue Fachlichkeit statt Anpassung, ein zusätzliches if statt Refactoring. Die Architekturentscheidung allein ändert an diesem Muster nichts.
Warum fällt es Teams schwerer, Funktionen zu entfernen, als neue hinzuzufügen?
Dahinter steckt der Additive Bias: Menschen lösen Probleme lieber durch Hinzufügen als durch Wegnehmen, selbst wenn das Weglassen die bessere und günstigere Lösung wäre. Studien stützen das. Eine plausible Erklärung ist der geringere kognitive Aufwand. Subtrahieren kostet mehr Denkarbeit als Addieren, schon in der Schule.
An welchen Stellen zeigt sich diese Neigung zum Hinzufügen in Softwareprojekten?
Auf drei Ebenen. Fachlich wird ergänzt statt angepasst oder entfernt, weil sonst Impact-Analysen nötig wären und niemand weiß, ob danach noch alles funktioniert. Im Code kommt bei schwacher Architektur und Scheinabdeckung durch Unittests lieber ein weiteres if dazu als ein Refactoring. Und im Testing werden Testfälle ergänzt statt gelöscht.
Warum wachsen automatisierte Testfallbestände immer weiter, statt bereinigt zu werden?
Weil in jeden Testfall Energie geflossen ist und Löschen sich nach Verlust anfühlt. Also kommt lieber noch einer dazu. Ob 1000 automatisierte Testfälle überhaupt Fehler finden, wird selten geprüft. Die Folge sind technische Schulden und Komplexität, während Wartbarkeit, Testbarkeit und Übersichtlichkeit verloren gehen.
Warum ist zu viel Funktionsumfang für Nutzer von Business-Software ein größeres Problem als für App-Nutzer?
Feature Fatigue beschreibt Unzufriedenheit, Frustration und Überforderung durch zu viele und unklare Features. Als Consumer wechselt man einfach die App. Ein Sachbearbeiter muss dagegen nutzen, was ihm vorgesetzt wird, ob er will oder nicht. Freude und Zufriedenheit mit dem Werkzeug spielen bei der Auswahl oft keine Rolle.
Kann Weglassen ein eigenes Qualitätsmerkmal von Software sein?
Ja. Die Frage “Was kann ich weglassen?” lässt sich an vorhandene Qualitätskriterien anschließen: Einfachheit, Bedienbarkeit, Wartbarkeit, Usability, User Experience, Testbarkeit. Ernsthaft angenommen haben sich dieses Themas bisher kaum Unternehmen. Selbst bei Apple, wo das Abschneiden alter Zöpfe zeitweise sichtbar war, werden die Geräte mit jeder Generation überladener.
