Software-Putzer?

Nico Josuttis schreibt in seinem Blog über Software-Putzmänner und die nächste IT-Revolution. Er schlägt darin vor, schlechte Softwarequalität einfach als Fakt hinzunehmen und nicht immer zu versuchen, die Qualität zu verbessern. Vielmehr ginge es darum, mit dieser schlechten Qualität umzugehen. Als eine mögliche Alternative schlägt er Software-Putzkolonnen vor, die hin und wieder kommen und dann im Code aufräumen.

Dazu fallen mir gleich ein paar Sachen ein.

Zuerst zum Akzeptieren schlechter Qualität: Wenn die Qualität wirklich schlecht ist, wirkt sich das mannigfaltig unangenehm aus. Selbst der Product Owner bemerkt es. Nicht nur durch die langsame Entwicklungsgeschwindigkeit sondern auch dadurch, dass er aus technischen Gründen seine Priorisierungen ändern und seine Stories anders aufschreiben muss.

Und ich habe auch gerade ein aktuelles Projektbeispiel zur Hand, dass sich das Aufräumen lohnt. Beim Kunden dümpelte ein Team bei 30 Story Points je Sprint rum. Irgendwann hat das Team festgestellt, dass umfangreichere Refactorings im Bereich CSS notwendig sind, um schneller zu werden. Sie haben die Refactorings in Angriff genommen und die haben viel länger gedauert als zunächst gedacht - das ist nach meiner Erfahrung fast immer so bei größeren Refactorings. Aber sie haben es durchgestanden, obwohl es sogar soweit ging, dass nicht mehr alle Entwickler während des Sprints beschäftigt werden konnten. Nach dem Refactoring hat die Geschwindigkeit des Teams deutlich zugelegt. Heute liegt die Geschwindigkeit bei 80 Story Points je Sprint.
Mindestens in diesem Fall hat sich das Aufräumen schnell gelohnt und es wäre finanzieller Irrsinn gewesen, das Refactoring nicht durchzuführen.

Und zu den Putz-Kolonnen kann ich gleich zwei Erfahrungen beisteuern.
Erstens: Wir hatten bei it-agile mal so ein Dienstleistungsprodukt im Angebot. Das war ein Ladenhüter. Daher gibt es das jetzt nicht mehr als explizites Produkt bei uns. Wenn jemand sich dafür interessiert, beleben wir es aber jederzeit gerne wieder :-)
Zweitens: Wir hatten in einem Projekt mal sowas wie eine Putz-Kolonne in ganz zarten Ansätzen. Das hat in meinen Augen nicht funktioniert. Zum einen liefern die Projekte dann noch schlechtere Qualität - die Putz-Kolonne wird es schon richten. Zum anderen musste die Putz-Kolonne ständig bei den Entwicklern nachfragen, was bestimmter Code bedeutet. Und damit wurde das Team dann doch wieder mit Putzarbeiten belastet.

Langer Rede kurzer Sinn: Ich vertrete genau den konträren Ansatz. Wir als Entwickler sind für die technische Qualität des Systems verantwortlich. Wer schlechte technische Qualität abliefert, verstößt aus meiner Sicht gegen den Code of Ethics unserer Zunft und sollte sich was schämen. Niemand wird uns die Zeit und das Geld zum Aufräumen geben und die Putz-Kolonne wird auch nicht kommen. Wir als Entwickler müssen die Sache selbst in die Hand nehmen und zu unserer Verantwortung stehen!

P.S.: Zum Code of Ethics: Punkt 3 lautet: "PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible." Das bedeutet meiner Meinung nach auch, hohe Qualität abzuliefern.

P.P.S.: Wer mehr darüber erfahren möchte, wie guter Code für agile Entwicklung aussieht und wie man den schreibt: ich werde auf der OOP darüber einen Vortrag halten.

Post bewerten