InfoQ: Komplexität rund um Einfachheit

Gerade ist ein InfoQ-Artikel The Complexity Around Simplicity erschienen. In dem Artikel wird eine "Erkenntnis" genannt, der ich zustimme: 'What is "simple" for one request may not be "simple" for the whole!'
Aber der genannten Konsequenz stimme ich so nicht zu: 'trying to simplify one part of the system may bring undue complexities in other parts of the system. There is a need to view the system as a whole.'
Das würde ja bedeuten, dass ich bei Projektstart doch alles wissen muss und letztlich agile Vorgehensweisen zu komplexen/schlechten Entwürfen führen müssen.
Ich würde aus der erstgenannten Erkenntnis eine andere Konsequenz ableiten: Die einfache Lösung muss für den Kern des Systems passen. Wenn das dazu führt, dass der Rand des Systems etwas komplexer zu realisieren ist, ist das vollkommen OK.
Konkretes Beispiel: Verteilte Transaktionen lassen sich mit EJBs verhältnismäßig einfach realisieren. Wenn ich keine verteilten Transaktionen brauche, bedeuten EJBs aber zusätzliche Komplexität. Aber woher weiß ich, dass ich keine verteilten Transaktionen brauchen werde? Ich kenne ja noch nicht alle Anforderungen. Ich kann es nicht wissen.
Viele Teams neigen dann dazu, EJBs auf Vorrat in das System einzubauen. Leider belasten sie dann das ganze System mit der damit einhergehenden Komplexität.
Ich gucke mir den Kern des Systems an, ob ich verteilte Transaktionen brauche. Wenn ich dort keine verteilten Transaktionen brauche, setze ich auch kein EJB ein. Wenn später dann am Systemrand verteilte Transaktionen benötigt werden, akzeptiere ich für diese paar Zeilen Code auch eine deutlich höhere Komplexität. Ich bin überzeugt davon, dass ich dadurch in der Gesamtsumme die einfachere Lösung bekomme.

Post bewerten