Boehrsi.de - IT und Gaming Blog

Es ist schon etwas länger her das in dieser Sammlung etwas geschrieben wurde, aber nun wird es mal wieder Zeit. Denn nach einem durchaus ausführlichen Gespräch mit einem guten Freund und Entwicklerkollegen, hab ich mal wieder neues Lesematerial für euch.
Heute geht es um das Thema Over-Engineering und das in verschiedenen Formen. Den Anfang macht dabei die oft angepriesene nutzerzentrierte Entwicklung von Anwendungen. Ein schönes Buzzword, welches quasi immer im Raum steht bei Anwendungen die für Endanwender gedacht sind, aber sehr oft und sehr schnell vergessen wird. Egal ob die kleine private Anwendung, ein internes Firmentool oder aber eine große App für einen Kunden, das Problem mit dem Over-Engineering ist allgegenwärtig.
Dies äußert sich quasi immer darin, dass man im stillen Kämmerlein entwickelt und entwickelt. Man baut Features, implementiert Abläufe und davon immer mehr und mehr. Manchmal hat man konkrete User Stories, manchmal hat man sich selber etwas überlegt, aber am Ende basiert alles meist auf Annahmen. Denn selbst die beste Marktanalyse kann nicht garantieren, dass die entwickelten Funktionen der Art und Weise wie der Endanwender mit der Anwendung umgehen wollen entspricht. Dies bekommt man im eingeschränkten Rahmen durch Tests raus, aber am besten einfach durch echte Nutzer, die die Anwendung wirklich im Alltag verwenden. Entsprechend gilt hier Release Early Release Often mehr denn je.

Natürlich muss ein minimales Feature-Set gegeben sein, aber genau dieses Wort minimal verliert man oft aus den Augen. Ich selbst habe dies gerade erst bei meiner Tessa App bemerkt. Als ich im Rahmen des oben genannten Gesprächs über die Entwicklung der App nachdachte, fiel mir auf das ich quasi 1 Jahr für mich entwickelt habe, bevor die Nutzer Zugriff auf die App erhielten. Ich hatte zwar konkrete User Stories, aber die letzten Monate der Entwicklung hätten definitiv auch parallel zu einem Beta Release und dem dazugehörigen Nutzer-Feedback stattfinden können. Dadurch hätten sich mitunter Änderungen an der Roadmap ergeben können oder ich hätte Flows frühzeitig optimieren können. Der Mehraufwand wäre gering gewesen, das potentielle Feedback hätte aber sehr wertvoll sein können. Eine verschenkte Chance, die man immer wieder aus den Augen verliert. Ich persönlich will versuchen mehr darauf zu achten, ab wann man wirklich einen MVP hat, welchen man tatsächlichen Nutzern einfach mal zeigen kann. Im Bereich der Early Access Indie Spiele wird dies teilweise sehr gut umgesetzt und zum Teil auch mit durchaus beachtlichem Erfolg.

Ein weiterer Punkt des Themas Over-Engineering ist im technischen Bereich zu suchen. Hier bediene ich mich dreist am Beispiel meines Entwicklerkollegen. Es geht darum einen Service zu entwickeln der mitunter diverse Sachen verbinden soll, auch externe Anwendungen und Schnittstellen, dabei aber nicht unbedingt eine gigantische Anzahl von Nutzern gleichzeitig bedienen können muss. Für ein derartig Setup kam dann von außen die Anforderung eine Microservice Architektur zu erstellen. Auch hier wieder ein tolles Buzzword, aber eben kein sinnvolles. Ein Service der nicht extrem skalieren muss, der ohnehin auf alle gegebenen Komponenten angewiesen ist und der nicht mit Georedundanz oder anderen komplexen Konzepten betrieben wird, muss einfach kein Microservice sein. Es gibt Bereiche wo dies sinnvoll ist, aber in diesem Fall sorgt eine solche Anforderung, die nebenbei erwähnt von nicht technischen Personen stammt, nur für extrem unnötige Komplexität. Ich will hier nicht für monolithische Software Werbung machen, aber zwischen einem einzelnen großen Haufen Code und einem hoch skalierbarem Microservice liegen eben auch viele Zwischenschritte.

Hier sollten die Anforderungen den technischen Leitern überlassen werden und ein System entwickelt werden, welches den Anforderung der Nutzer und Admins entspricht. Denn so ein Microservice Setup ist mitunter halt auch wesentlich schwieriger zu pflegen, als ein eher konventionelles Setup. Insofern kann ich nur immer wieder sagen, nutzt die Werkzeuge die zur Aufgabe passen und nicht die die aktuellem im Trend sind. Nur weil beim Verlegen von Glasfaserkabeln im Außenbereich Hightech-Bohrmaschinen verwendet werden, braucht ihr selbige nicht auch, um ein CAT-6 Kabel zu Hause durch die Wände zu führen. Kosten, Nutzen, ein einfacher Betrieb und eine gute Verfügbarkeit, vor allem aber auch die gute Nutzbarkeit für die Anwender und Admins sollten auf der Liste ganz oben stehen, nicht das allseits beliebte Buzzword-Bingo.