Hängen Clean Code und Business Value zusammen?

Echt jetzt? Schon wieder schlechter Source Code? Diese Frage taucht immer wieder auf. Anlass darüber nachzudenken, wie Clean Code und Business Value zusammenhängen: Machen Entwickler, die Clean Code schreiben, einen besseren Job als andere, die Features nur schnell runterhacken?

Meine persönliche Beobachtung

Wenn ich das erste Mal in neue Projekte reinschaue, finde ich immer Code Smells wie Gottklassen, duplizierte Logik, ungetestete Features oder Logik tief in einer UI-Komponente vergraben, die eine leicht zu testende Pure Function hätte sein können. Ist Clean Code Rocket Science, die nur wenige beherrschen? Oder ist Clean Code einfach nicht wichtig? Lasst uns darüber nachdenken.

Was soll guter Source Code bezwecken?

Wenn wir etwas als schlecht empfinden, erfüllt es nicht unsere Erwartungen. Arbeite ich mit schlechtem Source Code, wird meine Erwartung, schnell neue Features zu entwickeln, enttäuscht. Das weckt in mir das Gefühl, dass das Unternehmen aufgrund von vorheriger schlechter Arbeit Geld verliert.

Das bringt mich zu dem Punkt: Das Ziel von Source Code in der freien Marktwirtschaft ist es, so viel Geld wie möglich zu verdienen.

Wie verdient unser Source Code Geld? Eine Firma verkauft ein Produkt. Der Source Code ist, wie viele andere Sachen, ein wichtiger Bestandteil des Produkts. Am Ende haben Stakeholder und Kunden hoffentlich mehr Geld eingezahlt, als an Gehältern, Lizenzen, Marketing etc. ausgegeben wurde.

Aber Moment mal, bis jetzt wurde Clean Code in diesem Abschnitt gar nicht erwähnt – ist Clean Code  nicht wichtig?

Drei Gedankenexperimente

Lasst uns ein paar Gedankenexperimente durchgehen. In den folgenden Diagrammen repräsentieren die Zahlen eine abstrakte Geldeinheit. Der genaue Betrag ist nicht wichtig, vielmehr das Verhältnis zwischen den Diagrammen.

1. Produktentwicklung mit einem Release

Wir releasen ein neues Produkt. Das erste Team macht Rapid Prototyping und hacked viele Features irgendwie zusammen. Das zweite Team investiert Zeit in Clean Code und setzt daher nicht so viele Features um. Die Kunden zahlen für das Produkt und nicht für die Qualität des Source Codes. Daher wird die Firma mit dem ersten Team wahrscheinlich mehr Geld verdienen.

2. Produktentwicklung mit fünf Releases

Aber unser Produkt lebt hoffentlich länger als nur ein Release. In diesem Fall kann das zweite Team wahrscheinlicher mit gleichbleibendem Tempo neue Features einbauen. Dadurch können sie neue Kunden gewinnen beziehungsweise mehr Geld mit bestehenden Kunden umsetzen. Dagegen muss das erste Team wahrscheinlich Bugs fixen, neue Features brauchen aufgrund der technischen Schulden länger. Daher sie können nicht so viele Features umsetzen, was ihren Umsatz langsamer wachsen lässt.

3. Produktentwicklung mit Konkurrenz

Natürlich entscheiden wir uns dazu, das zweite Team zu sein. Nach unserem ersten Release stellen wir fest, dass die Konkurrenz ein ähnliches Produkt herausgebracht hat, das uns Kunden abwirbt und unseren Gewinn reduziert.

Wie schafft es die Konkurrenz, unsere Kunden abzuwerben?

• Haben sie mehr in Clean Code investiert, so dass sie jetzt mehr Features umsetzen können als wir?
• Haben sie sich das Investment in Clean Code gespart und nur schnell Features herausgebracht? In dem Fall werden sie wahrscheinlich mit vielen Bugs zu kämpfen haben, was die künftige Entwicklung ausbremst.
• Haben sie ein größeres Team, sodass sie mehr umsetzen können?
• Oder haben sie sogar weniger Features entwickelt, aber diese kommen besser beim Kunden an?
• Oder haben sie ein besseres Marketing als wir?
• Oder vielleicht…

Weiterführende Gedanken

Das dritte Szenario zeigt: Es gibt viele Stellschrauben, an denen wir drehen könnten. Es ist meist schwer zu sagen, welche Stellschraube zu welchem Output führt. Leider haben wir nicht genug Zeit, um an allen Stellschrauben zu drehen. So könnten wir:

• Code Qualität verbessern, was uns ermöglicht, Features schneller zu entwickeln und damit den Umsatz steigern.
• In die Evaluation der Benutzerdaten investieren. Dadurch haben wir weniger Zeit für Features. Aber wenn wir dafür bessere Features entwickeln, steigert das ebenfalls unseren Umsatz. Es hilft auch der Code Qualität, da wir nun weniger Features warten müssen.

Die Moral von der Reflexion

Der bestehende schlechte Source Code kann ein vernünftiger Trade-off gewesen sein, um andere Stellschrauben zu priorisieren. Ein erfolgreiches Produkt besteht aus vielen Bausteinen. Clean Code ist wichtig, um regelmäßig neue Features umsetzen zu können. Ein wichtiger Teil der Arbeit eines Entwicklers ist es, zu entscheiden, wie viel seiner limitierten Zeit er in Clean Code investiert und wie viel in andere wichtige Aspekte wie neue Features, Refinements, etc.

---

Über den Autor