Zeitlose Prinzipien, Heuristiken und andere vermeintlich esoterische, aber in Wirklichkeit sehr nützliche Dinge, die Softwareteams wissen und berücksichtigen sollten - aber leider tendenziell ignorieren - weil Hype und der Glanz vermeintlich moderner Technologien diese Grundregeln in eine finstere Ecke des Unterbewusstseins verbannt haben ...
Sie hören von Einfachheit (im Gegensatz zu Eindrücklichkeit [impressiveness]), Kohäsion, Modularität, Erst-Denken-dann-Coden sowie einigen grundlegenden Aufgaben von Softwarearchitekten.

Zielpublikum: Softwareentwickler und -architekten
Voraussetzungen: Grundlagen von Software-Engineering, Erfahrung mit Entwicklungsprojekten
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Zu Beginn werde ich Grundlagen, Prinzipien und Heuristiken unterscheiden, und dabei ein wenig über Entwicklungsorganisationen schimpfen. Danach tauchen wir in ausgewählte Themen des „methodischen Software-Engineerings" ein.
Einige Beispiele, über die ich im Vortrag sprechen werde:
* Einfachheit - auch als KISS-Prinzip bekannt, wird oft zugunsten von
„schick" oder „modern" vernachlässigt. Ich spreche LOC als die einfachste und möglicherweise nützlichste Metrik an, und warum wenig oft besser ist (Sicher ein Grund, warum Microservices seit einigen Jahren so angesagt sind).
Sie hören von typischen Kompromissen bezüglich Einfachheit – beispielsweise können Sie Programmierung vereinfachen auf Kosten komplizierter Konfiguration und aufwendigen Betriebs.
* Kohäsion - also die Gruppierung zusammengehöriger Elemente - wird allgemein als hochgradig nützlich angesehen. Allerdings ist Kohäsion immens schwierig zu messen, und noch schwerer zu erreichen.
Sie werden die Problematik widersprüchlicher Kriterien für Kohäsion kennenlernen.
* Modularität gilt zu Recht als die Mutter aller Entwurfsprinzipien - dennoch lohnen ein paar Gedanken in ihre Richtung: Ich werde „Zusammensetzbarkeit" als einen weiteren Begriff erwähnen - womit wir hoffentlich zu noch besseren Kriterien für den Entwurf nützlicher Module kommen können.
* Grundlegende Aktivitäten und Tätigkeiten in Softwarearchitektur und -engineering, wie beispielsweise „Erst-Denken-dann-Coden", also die saubere Trennung von Problem- und Lösungsraum: Erst das Problem verstehen, dann über Lösungen nachdenken.
* Wenn wir so weit gekommen sind, sprechen wir Dokumentation an: Die ist oft nützlich, aber niemals ausreichend, um gute Systeme zu implementieren. Verlassen Sie sich niemals auf Dokumentation, sondern arbeiten Sie bei der Implementierung mit.
Finden Sie positive und negative Abweichungen vom Soll-Zustand, und berücksichtigen Sie solche Abweichungen in Entwürfen.