Abstrahieren und vereinfachen liegt in der Natur des Menschen. Wir alle haben es natürlich gerne wenn eine Aufgabe “leicht” zu bewältigen ist oder ein Sachverhalt “einfach zu begreifen” ist. Eine grundlegende Eigenschaft dabei ist es, dass wir Dinge “ausblenden” die für die aktuelle Aufgabe nicht relevant sind oder deren genaue Zusammenhänge wir nicht bis ins Detail verstanden haben müssen um die Aufgabe zu lösen oder den Sachverhalt zu verstehen. Oftmals reicht es auch aus, die Hintergründe einmal umfassend bearbeitet zu haben und dann mit den gewonnenen Erkenntnissen und ggf. auch Erfahrungen weiter zu arbeiten. Jeder der ein Kraftfahrzeug fährt, hat sich (hoffentlich) einmal mit der dahinter stehenden Physik beschäftigt – doppelte Geschwindigkeit vervierfacht die Energie usw. Das alles setzt ein geübter Fahrer zusammen mit ggf. weiteren Erfahrungswerten ein um sein Fahrzeug im Verkehr sicher zu führen.
Wir Menschen sind auch Meister darin immer mehr dieser Denkarbeit zu automatisieren und uns somit das Leben noch leichter zu machen. Waren die ersten Computer noch groß und nur mit dem notwendigen Fachwissen zu bedienen, so benutzen wir heute fast schon wie selbstverständlich ein Smartphone dessen technische Komplexität um mehrere Größenordnungen über den ersten Großrechnern oder gar Heim-PCs liegt. Durch den Einsatz von Technik und entsprechenden Schnittstelle (der Fachmann spricht vom User-Interface) kann heute jeder mit minimalen Vorkenntnissen ein Smartphone zumindest grundlegend bedienen. Natürlich gibt es auch weiterhin die PowerUser bzw. Spezialisten die nochmals mehr aus dem Gerät “herausholen” bzw. auch bei bestimmten Fehlerbildern Abhilfe schaffen können (oder zumindest einmal wissen wo man nachschlagen kann um ein Problem zu beheben).
So sehr auch ich die Errungenschaften der Technik und die intuitive bzw. einfach Bedienung im privaten Umfeld zu schätzen weiß, um so mehr bin ich im Arbeitsalltag doch darauf angewiesen, dass meine Software-Werkzeuge (z.B. eine integrierte Entwicklungsumgebung, ein Framework, etc.) mir zwar eine zügige Arbeitsweise erlaubt, aber mir auch die Möglichkeit gibt auf die Details sofern notwendig einzugehen.
Mit der Entwicklung von Software ist man ständig mit der Thema der Vereinfachung konfrontiert – kein Datenbankmodell kann die Realität in Gänze abbilden. Es ist und bleibt ein Modell und so lange es den Anwendungsfall ausreichend präzise beschreibt ist es genau das was wir brauchen.
Nur was ist “genau das was wir brauchen”? Insbesondere bei “Standard-Software” wie Office-Paketen (egal ob kommerziell oder Opensource) beobachtet man den Hang zu zunehmendem Funktionsumfang – die Software-Pakete werden immer größer (ersichtlich an der Größe der Programmdateien bzw. der Pakete) und auch immer mächtiger. An einigen Stellen kann man sich nicht des Eindrucks erwehren: Das Ding macht wesentlich mehr als 80% der Benutzer jemals benötigen werden. So lange die einfachen Tasks durch die Feature-Fracht nicht aufwändiger werden habe ich damit auch weniger ein Problem.
Am anderen Ende der Skala gibt es jedoch etwas das mir um so mehr Sorgenfalten ins Gesicht treibt – der Hang alles “neu” und “super-simpel” zu machen. Teilweise ist das einer geänderten Technik geschuldet (man hat auf einem Smartphone weniger Platz und andere Benutzerinteraktion als an einem Rechner). Aber an vielen Stellen geht man in meinen Augen viel zu weit und lässt wichtige Funktionalität bzw. Interoperabilität vermissen. Klassiker hierfür sind diverse “Mail-Apps” – hier wird ein Mail-Client emuliert der noch dazu die eigentliche Abwicklung der e-mail über eine Rest-API in HTTP mit dem Mailanbieter realisiert. Aus technischer Sicht absolut gruselig, macht es doch den Notbehelf eines Webmail-Interface zum “neuen Standard”. So Dinge wie mehrere e-mail-Konten in einer Client-Applikation sind mit diesen Krücken natürlich nicht drin. Dafür sind sie simpel zu bedienen. An dieser Stelle kann ich es noch halbwegs verschmerzen, denn nur ein kleiner Teil der Anwender wird tatsächlich mehrere Konten haben (auch wenn es sich bei einer ehrenamtlichen Tätigkeit anbieten würde) oder den Bedarf ausgefeilter Verschlüsselung über Plugins.
Die App hat in diesem Fall aber auch einen klaren Benutzerkreis und das sind eher unbedarfte e-mail-User, die das Medium einfach nur mit möglichst geringem Aufwand nutzen möchten. Was das für die Qualität der e-mails bzw. die möglichen Einfallstore für Betrug aller Art zur Folge hat, steht dann nochmal auf einem anderen Blatt. Für diesen Anwendungsfall lasse ich es gerne stehen: “Das ist das was der Anwender möchte und braucht”.
Gänzlich anders sieht die Sache bei Software im Berufsalltag aus, insbesondere bei speziell für bestimmte Anwendungsbereich entwickelter Software. Hier vereinfachen zu wollen oder es auch nur zu versuchen ist meistens nicht zielführend. Denn in diesem Falle sind die Anwender Spezialisten auf ihrem Fachgebiet und möchten durch die Software möglichst optimal unterstützt werden. Nun ist es in der Regel aber leider auch so, dass Fachgebiete eine gewisse Komplexität mit sich bringen (sonst bräuchte man in der Regel keine Ausbildung für einen derartigen Job bzw. man könnte sich auch Berufserfahrung sparen). Hier als Software-Entwickler zu sagen: “Das ist zu komplex, ich reduziere das einfach mal soweit es irgendwie geht” wird nicht zur Akzeptanz bei den Anwendern beitragen. Denn wenn die Sachverhalte sehr einfach sind, reicht im Zweifelsfalle sogar eine einfache Text-Datei oder eine Tabellenkalkulation aus, um dem Problem organisatorisch Herr zu werden. Von dieser Sorte Problematik gibt es wohl eine ganze Menge, aber sie erreichen die Software-Entwicklungsabteilung meistens nicht mehr, da es ja schon fertige Lösungen wie eine Tabellenkalkulation gibt.
In der Entwicklung landet als meistens das, was etwas mehr Komplexität mit sich bringt – das man als Entwickler akzeptieren und auch in der Software und seinem Datenmodell korrekt abbilden. Was dabei “gefühlt” erst einmal auf der Strecke bleibt, ist die intuitive Bedienung einer Software. Allerdings liegt hier ein gewaltiger Denkfehler bzw. Trugschluss vor: Die Anwendung muss nicht zwingend sofort einfach erfassbar sein, denn der Anwender kennt den Hintergrund die unterstützten Abläufe. Das heißt nicht, dass man die Benutzeroberfläche “unaufgeräumt” lassen kann oder sollte, auch ein Handwerker mit einer vollwertig ausgerüsteten Werkstatt mit einer Vielzahl von Vorräten und Werkzeugen wird diese ordentlich und thematisch sortiert ablegen damit man sie wieder findet.
Meine leidige Erfahrung in den letzten Jahren ist leider, dass man auf Biegen und Brechen versucht eine Software “einfacher” zu gestalten in dem man Funktionen einfach weglässt. Bei bestehender Software kann das schon einmal ärgerlich für den Anwender werden – eine neue Version und eine benötigte Funktionalität ist nicht mehr vorhanden. Sowas möchte keiner erleben, und wer es schon einmal erlebt hat und dann feststellen musste: Es gibt keinen “Rückwärtsgang” in Form eines Downgrades der wird mir sicherlich beipflichten, dass er sich dabei doch etwas verschaukelt vorkommt. Ich rede hierbei absichtlich vom totalen Wegfallen einer Funktionalität und nicht dem Anpassen bzw. Ersetzen einer Funktionalität. Auch das kommt immer einmal wieder vor: das bestehende Modell war unzureichend, aber um besser machen zu können greifen einige Dinge nicht mehr so ineinander wie man es ggf. bisher gemacht hat. Hier muss man als Entwickler sehr aufpassen und dem Benutzer zumindest auf den Übergang vorbereiten bzw. ihm eine Hilfestellung anbieten.
Ein ebenfalls häufig beobachtetes Problem ist es, dass eine Re-Implmentierung einer bestehenden Anwendung ansteht, z.B. weil die zu Grunde liegende Technik nicht mehr aktuell ist und somit eine weitere Entwicklung unmöglich macht. Hierbei wird häufig ohne Not das bestehende Datenmodell erst einmal auf die Seite gelegt und auf der grünen Wiese angefangen. In meinen Augen ein gravierender Fehler, denn man macht sich in der Regel die Arbeit doppelt und dreifach. Viel günstiger ist es erst einmal das bestehende Modell mit den Anwendern zu besprechen. Das ist nicht immer 1:1 möglich, aber mit ein wenig technischen und logischem Verständnis sollte dieser Schritt jedem Entwickler gelingen.
Meine Erfahrung zeigt mir, dass sich dabei durchaus Vereinfachungsmöglichkeiten ergeben werden, allerdings sollte dies durch den Nutzer angestoßen werden. Jemand der tagtäglich mit einer bestehenden Anwendung arbeitet kennt im Zweifel die Stolperstellen oder ungenutzten Funktionen besser als der Entwickler der zum ersten Mal mit einer Anwendung oder einem Fachgebiet in Kontakt kommt. Ein regelmäßiger Nutzer wird klar sagen können: Diese Funktion habe ich seit mehreren Jahren nicht mehr genutzt oder aber auch: “Die Idee dahinter ist gut, aber in der Praxis hat es sich nicht bewährt”. Im ersten Fall ist die Lösung beim Rewrite recht einfach: Man muss sich nicht mehr um das Problem kümmern und sich darüber den Kopf zerbrechen. Der zweite Fall ist etwas kniffliger aber wahrscheinlich auch lohnenswerter hier Energie und Zeit zu investieren um möglicherweise eine praxistaugliche Lösung zu erhalten.
Man spricht zwar heute immer gern davon, dass man agil arbeitet und somit in kleinen Iterationsschritten voran gehen kann und will, aber das heißt noch lange nicht, dass es nicht lohnenswert ist, sich zu Beginn der Entwicklung einmal grob mit den Abläufen und Bedürfnissen der Anwender auseinander zu setzen. Oftmals habe ich leider beobachten müssen, dass diese Aufgabe “exklusiv” von Verantwortlichen (z.B. dem Product-Owner im SCRUM-Umfeld) für sich beansprucht wird. Dieses Nadelöhr des Wissens macht es im Zweifelsfalle für den Entwickler bzw. das Entwicklungsteam schwer bis unmöglich sinnvolle Software zu schreiben bzw. den Wunsch des Anwenders möglichst exakt beim ersten Wurf zu treffen.
Es mag jetzt vielleicht etwas “altmodisch” klingen, aber ich bevorzuge es immer noch zu Beginn eines neuen Projekts bzw. einem Rewrite mich mit den Zusammenhängen und bestehenden Daten zu beschäftigen. In aller Regel fängt man heute nämlich nicht bei Null an, sondern es gibt bereits Abläufe und vielleicht auch etwas versteckt schon Datenmodelle (vielleicht nicht normalisiert sondern etwas krude in einer Excel-Tabelle). Auch wenn mir hier sicherlich einige Leute vehement widersprechen werden (was ok ist), so halte ich ein solides Datenmodell (z.B. als relationales Datenbank-Schema) für das Fundament der meisten Anwendungen im betrieblichen Umfeld. Man muss sich hier im Zweifel bewusst sein, dass derartige Anwendungen nicht nach wenigen Monaten wieder eingemottet bzw. entsorgt werden, sondern häufig Jahre und Jahrzehnte ihren Dienst verrichten müssen. Auch wenn der Vergleich vielleicht ein wenig hinkt, so ist er doch eine recht hübsche Analogie wie ich finde: Für ein temporäres Event wie ein Festival oder eine Messe arbeitet man natürlich anders als wenn man ein Gebäude für mehrere Jahre baut. Kaum jemand würde auf die Idee kommen ein Gebäude ohne Fundament zu bauen, wenn es auch nur ein Jahr halten soll, von einem Wohnhaus, dass ggf. mehrere Jahrzehnte halten soll ganz zu schweigen.
Fazit: Agil und schnell muss nicht zwingend heißen, dass man Analysen und Verständnis hinten anstellen kann, erfahrungsgemäß rächt sich das spätestens nach einigen Iterationen, was dann ggf. wieder ein vollständiges Rewrite oder massive Umstellungen erfordert. Dann hat man mit schnell und agil nicht viel gewonnen.