Siebenhundertzwölf

Fast immer wenn bei einer bestehenden Anwendung neue Features gewünscht werden, gibt es Probleme mit der Architektur.

Wenn ich ein neues Projekt aufsetze, habe ich im Allgemeinen vorher ausführlich mit dem Kunden abgestimmt, was denn die neue Software können soll, und wie die Schnittstellen aufgebaut sein sollen.
Ich schreibe das alles ziemlich detailliert in der Spezifikation nieder, die der Kunde dann noch durchliest, und sein OK dazu gibt, bzw. noch Gelegenheit hat, Änderungswünsche zu äußern.
Wenn die Spezifikation erst durchgewunken ist, beginnt die Umsetzung (vorher habe ich vielleicht schon Prototypen erstellt, von denen Screenshots in der Spec abgebildet sind).

Wenn die Spezifikation gut durchdacht war, dann ist die Umsetzung größtenteils straightforward zu bewerkstelligen: Code schreiben, testen, debuggen, dokumentieren, etc.
Bei größeren Projekten kriegt der Kunde zwischendurch mal eine Work-in-Progress Version, wenn er will. Ansonsten time ich das Release so, dass er es rechtzeitig zum vereinbarten Termin bekommt.
Normalerweise ist der Kunde dann erst mal zufrieden (in seltenen Fällen passierte es auch schon, dass ich Kleinigkeiten nachbessern musste).

Nachdem die Software ein oder zwei Jahre im Einsatz war, fällt es Kunden dann manchmal ein, dass sie die eine oder andere Funktionalität auch noch gebrauchen könnten, und ich bekomme einen Auftrag für eine neue Version (da ich mittlerweile ja schon einige Jahre im Geschäft bin, ist dieser Fall deutlich häufiger als ein komplett neues Projekt).
Tja, und da ist es dann häufig der Fall, dass diese neuen Funktionen überhaupt nicht mehr ins bisherige Konzept passen.
Wären diese Erweiterungen von vornherein abzusehen gewesen, hätte ich das natürlich bei der Architektur berücksichtigen können. Aber so passen meine Objekte nicht mehr so recht zu den neuen Anforderungen.

Was macht man dann als Entwickler?
Flicken.

Da werden dann also neue Methoden irgendwie reingepatched. Das ist nicht gerade sauber und elegant. Die Alternative wäre es, das gesamte Projekt noch einmal ganz neu aufzusetzen. Aber das will weder ich (zu langweilig, und ich hänge an meinem alten Code) noch der Kunde (der ja den zusätzlichen Aufwand bezahlen müsste).
Solch reingeflickter Code ist natürlich fehlerträchtiger und die Software läuft tendenziell weniger stabil und robust. Da kommen zusätzliche Abfragen rein, die vorher gar nicht nötig gewesen wären, was die Performance bremst.
Eine oder zwei solche neue Versionen mag eine Software ja aushalten, aber irgendwann ist das ganze nur noch Flickware. Features, die niemand benutzt, weil man sie einfach nicht braucht, oder weil sie zu umständlich zu bedienen sind.

Jede Software hat irgendwo ihr Optimum. Wenn man sie danach noch weiter verbessern will, beginnt die Featuritis, und man sollte sich wirklich überlegen, ob man einen radikalen Schnitt macht, und stattdessen etwas Neues beginnt.