Unnützes und Techn. Schulden

Im vorigen Beitrag ging es um Waste aus Featuresicht, aber natürlich wird sich auch aus technischer Sicht nach einiger Zeit einiges an Müll ansammeln.

Wichtig ist aus meiner Sicht Waste und Technical Debt zu unterscheiden. Waste ist einfach nur im Quellcode vorhanden und macht keinen Sinn, Debt hingegen besteht, wenn durch Code in Zukunft Aufwand (der “Zins”) entsteht.

Beispiel Waste Debt
Nicht funktionierende Unit Tests 80% 15%
Schlecht testbarer Code 10%
Selbstentwickelte Komponenten statt Standard-Controls 95% 1%
Manuelles editieren von generiertem Code 80%
Nicht “genutzte” Dependency Injection 90% 5%
Puristisches MVVM (“at any price”) 50% 25%

Ich habe die Beispiele einmal lieber allgemein gehalten, nicht dass sich ehemalige oder aktuelle Projektkollegen angesprochen fühlen :)

Wenn beispielsweise eine Unit Test Suite nicht mehr weitergepflegt wird, dann handelt es sich hauptsächlich um Waste, denn wahrscheinlich hat niemand davon einen Nutzen. Es ist beinhaltet auch in gewissem Maß technische Schulden, denn falls jemand die Unit Tests doch wieder reaktivieren will und nicht völlig von vorne beginnen will, muss man zuerst die Tests wieder nachpflegen.

Selbstentwickelte Controls sind auch ein offensichtlicher Waste. Zuletzt bin ich mal wieder darauf gekommen, dass ich mal zu Studentenzeiten für Windows Forms einen ZoomListView gebaut habe. Der hatte im Gegensatz zum Standard ListView total geile Features mit direktem Databinding auf Business Objekte, geringem Memory Overhead, stufenloosem Zoom(!) und guter Performance selbst bei 1 Milllion Einträge. Für die damalige Anwendung wäre der Standard-ListView meistens aber auch OK gewesen. Mein ListView war sehr stabil, ich kann mich an keine großen Bugs erinnern die gefixt werden mussten, insoweit gab es zumindest keine techn. Schulden. Bei Null sind diese jedoch nie. Bei anderen Projekten habe ich auch selbst gebaute Komponenten erlebt, die sowohl Waste und Technical Debt in sich vereinten.

Gerade bei architektonischen Grundentscheidungen ist manchmal die Unterscheidung zwischen Waste und No-Waste gar nicht so einfach. In Quality Spy habe ich z.B. eine MVC-+MVVM Architektur auf Basis von Magellan Framework gewählt. Dafür, dass es nur ca. 6 oder 7 Pages in der Anwendung gibt ist das schon viel mehr Aufwand an Basiskonfiguration etc.

Aber solche Spielchen brauchen wir Entwickler nun einmal wie Luft zum atmen, insoweit keine Bange, es gibt genug anderen Müll wegzubringen der wirklich stinkt.

Blog-Serie