“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.
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.
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:
Und schwuppdiwupp sind sie da: die technischen Schulden, die Komplexität. Oder weg: die Wartbarkeit, die Testbarkeit, die Übersichtlichkeit.
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.
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?