JEE – Just Enough Engineering

Please find the english version on medium.com

‘JEE’ positiv besetzen: eine Anti-Overengineering-Checkliste

Wikipedia definiert Over-Engineering als

the designing of a product to be more robust or complicated than necessary for its application.

Over-Engineering verletzt zwei bewährte Prinzipien: KISS und YAGNI. Auch die Autoren des Agilen Manifests haben dazu eine klare Haltung:

Simplicity — the art of maximizing the amount of work not done — is essential.

Over-Engineering kann viele Ursachen haben, und meistens resultiert es sogar aus guter Absicht: Als Software-Ingenieure wollen wir Systeme richtig bauen. Wir möchten, dass unser Code generisch, erweiterbar und skalierbar, robust und gut dokumentiert ist. Wir wollen all die hübschen Patterns anwenden, die wir beim Lesen von Gang of Four gelernt haben. Aber sind diese Qualitäten und Charakteristika wirklich Voraussetzungen für guten Code?

Nein.

Guter Code ist Code, der funktioniert und mit dem man arbeiten kann. Er ist lesbar, getestet und erweiterbar. In anderen Worten: Guter Code ist wartbarer Code.

Tunnelblick im eigenen Mikrokosmos

Seien wir ehrlich: Man entwickelt im eigenen Mikrokosmos schnell eine Art Tunnelblick. Und verliert dabei die eigentliche Frage aus den Augen: Braucht man dieses Stück Code wirklich? Oder löst es möglicherweise ein Problem, das gar nicht existiert? Gibt es einen Kompromiss?

Manchmal meinen wir es besser zu wissen als der Benutzer unserer Anwendung. Eine Instanz dieser Hybris ist uns in einer Brainstorming-Session über ein neues Feature der Software, die wir bauen, passiert. In der Diskution entwickelten wir die Idee, einen Vorgang zu automatisieren. Es würde dem Nutzer Arbeit abnehmen – für nur zehn Entwickler-Tage.

Die Antwort unseres Kunden war nicht nur interesant, sie war ein Augenöffner: “Wir werden diese Funktion geschätzt ein Mal pro Jahr benutzen. Automatisieren rechnet sich nicht.” War unsere Idee aus technischer Sicht interessant? Ja! War unsere Idee das Geld unseres Kunden wert? Definitiv nicht!

Das Takeway: Schreibe keinen Code, der ein Problem löst, das es gar nicht gibt.

Die folgende Liste ist das Ergebniss einer projektübergreifenden Diskussion zu diesem Thema – ohne Anspruch auf Vollständigkeit. Vielleicht hilft sie Ihnen weiter, wenn Sie vor einer Design-Entscheidung stehen.

Überlegungen für eine Design-Entscheidung

• YAGNI: Brauchen wir es wirklich? Brauchen wir es jetzt? Dabei ist die Perspektive der Fachabteilung besonders wichtig: Code und Features zahlen sich nur aus, wenn sie auch genutzt werden. Und: Auch nicht-genutzter Code verursacht Wartungskosten.
  
• KISS: Ist die Komplexität der Lösung angemessen? Gibt es eine einfachere Lösung? 
  
• Kann der Nutzen jemandem erklärt werden, der keinen Entwickler-Hintergrund hat? Dahinter verbirgt sich die Frage: Wer braucht es? Und wofür?
  
• Sind die nicht-funktionalen Anforderungen definiert? Oder haben wir es möglicherwise mit einem Fall von “voreiliger Optimierung” zu tun? Premature Optimization ist laut Donald Knuth die Wurzel fast jeden Übels in der Software-Entwicklung.
  
• Muss die Architektur-Entscheidung jetzt getroffen werden? Ist es der “last responsible moment“?
  
• Entsprechen Zeit und Aufwand einer Lösung dem, was der Kunde braucht? Könnte ich die Lösung vor dem Kunden vertreten? Würde der Kunde sie bezahlen, wenn ich ihn explizit fragen würde? Oder kurz: Ist die Lösung ihr Geld wert?
  
• Refactorings: Könnte man den Code in kleineren Schritten verbessern? Statt Big-Bang-Refactorings sollte man Baby-Schritte machen.
  
• Not-invented-here-Syndrom: Existiert schon ein Produkt, das mein Problem löst?
  
• “Shiny new framework”: Klar, es ist sexy und neu und hip. Aber ist es auch reif genug für den Einsatz im Geschäftsumfeld? Ist die neue Abhängigkeit es wert? Oder kostet deren Integration mehr Arbeit, als sie spart?

Soweit die Checkliste aus unserem Projekt: Was hilft Ihnen, Over-Engineering zu vermeiden? 

---

Über den Autor

Alexandros Kotzias ist seit 2015 als Software engineer und Architekt bei MaibornWolff tätig. Er interessiert sich für Themen wie Clean Code, Continuous Delivery und DevOps. Was ihm im Herzen liegt sind Teams, Kultur und Menschen, deswegen sind Diversity und Inclusion für ihn besonders wichtig. Privat fährt er gerne Fahrrad und macht Krafttraining.