Clean Development Mindset
Softwareprojekte scheitern selten aus einem einzigen Grund. In der Praxis sind es immer mehrere Probleme, die gleichzeitig wirken und sich gegenseitig verstärken.
Wir bauen, was gebraucht wird, nicht was vorstellbar ist.
Was erfolgreichen Projekten fehlt
Eines der häufigsten Probleme ist fehlender Fokus, und zwar nicht nur in der eigentlichen Code-Entwicklung, sondern auf allen Ebenen: in der Produktvision, im Prozess, im gemeinsamen Verständnis davon, wozu eigentlich eine Softwarelösung gebaut werden soll. Eng damit verbunden ist die Frage der Verantwortlichkeit. Wir verwenden dabei den englischen Begriff Accountability: Wer übernimmt dafür Verantwortung, welches Ergebnis wie entsteht? Wenn das unklar bleibt, kann sich kein guter Erfolg einstellen.
Wenn Erfolge und Misserfolge nicht gemessen werden, bleibt es Gefühlssache, was funktioniert und was nicht. Wenn gleichzeitig Feedbackzyklen zu lang sind, entscheiden Teams wochenlang in die falsche Richtung, bevor eingelenkt wird.
Hinter diesen Problemen stecken Qualifikationslücken, die oft erst sichtbar werden, wenn es zu spät ist. Das Clean Development Mindset setzt daran an: nicht als Methode, sondern als professionelle Haltung.
Die Kernprinzipien
Kundenproblem im Fokus
Technische Entscheidungen dienen immer einem konkreten Problem. Wenn eine Entscheidung nicht auf ein Kundenproblem zurückzuführen ist, ist sie erstmal falsch. Das klingt einfach, aber in der Praxis braucht es Disziplin, diesen Fokus zu halten. You Ain't Gonna Need It (YAGNI) und Keep it simple, stupid (KISS) sind zwei Praktiken, die in der Branche als selbstverständlich gelten und die dennoch im Alltag systematisch gebrochen werden.
Es bleibt dabei: Wir bauen, was gebraucht wird, nicht was vorstellbar ist.
Entwurf vor der Implementierung
Bevor Code geschrieben wird, entsteht ein Plan. Das beginnt auf einer Ebene, in der noch kein technisches Verständnis notwendig ist: Wir schauen uns die angedachte Nutzeroberfläche an, bestimmen Interaktionen und arbeiten uns von dort aus schrittweise in die Tiefe. Mit Flow Design, einer Entwurfsmethode, die von Stefan Lieser entwickelt wurde, lässt sich das zum Beispiel so strukturiert durchführen, dass alle Produktverantwortliche am Ende eine Vorstellung davon haben, wie der Code strukturiert ist, bevor die erste Zeile geschrieben ist.
Durchstich zuerst
Nach jeder Iteration (egal ob Meilenstein, Sprint oder Unteraufgaben eines größeren Features) muss ein Inkrement mit einem Mehrwert geliefert werden. Kein Inkrement, das nur zur Hälfte funktioniert, oder Qualitätsmängel enthält, besteht die Definition of Done als Qualitätskontrolle. Der Durchstich zwingt Teams, früh mit echten Daten und echten Nutzern zu arbeiten, statt wochenlang im leeren Raum zu entwickeln. Und er macht Fortschritt sichtbar für das Team, seine Stakeholder und mögliche Endkunden.
Kollaboration im Team
Wissen gehört dem Team, nicht Einzelpersonen. Inselwissen ist ein Risiko: für die Qualität, für den Durchsatz, und für den Fall, dass jemand krank wird oder das Team verlässt (dazu kann man auch bereits einen 2-wöchigen Urlaub zählen). Wir arbeiten mit Pair Programming, regelmäßigen Abstimmungsrunden, synchronen Code-Reviews und gemeinsamen Entwürfen. Nicht als Prozess-Overhead, sondern als Teil der Arbeit. Teams, die so arbeiten, hören auf, nur gut zu sein: sie werden ausgezeichnet.
Messen & Automatisieren
Erfolgsmessung ist nur dann nachhaltig, wenn sie nicht von manueller Disziplin abhängt. CI/CD automatisiert die Lieferpipeline, Kennzahlen wie Cycle Time und Throughput lassen sich automatisch aus einem gepflegten Board ziehen. Beides schafft die Grundlage für die entscheidende Frage: Erzeugt das Gelieferte tatsächlich Wert?
Evidence Based Management gibt dafür den Rahmen: Es verschiebt den Blick weg von dem, was fertig wird, hin zu dem, was dem Kunden tatsächlich nützt.
Qualität ist nicht verhandelbar(und nicht teuer)
Tests, Code-Reviews und ein sauberer Entwurf sind Teil der Arbeit. Keine Extras, keine Nice-to-haves, keine Punkte, die wegverhandelt werden, wenn ein Termin drückt. Wer Qualität opfert, um Geschwindigkeit zu gewinnen, zahlt es später mit Zinsen zurück. Teams, die konsequent in hoher Qualität arbeiten, liefern verlässlich und planbar. Teams zu qualifizieren kostet am Anfang, aber der Aufwand amortisiert sich schnell und einmal gelernt wird es unmöglich in alte Muster zu verfallen.
Qualität ist daher keine Frage des Budgets, sondern der Haltung.
Die Clean Development Werte
Die Kernprinzipien beschreiben das Wie. Das Warum dahinter kommt aus einem Werte-Fundament, das wir nicht selbst erfunden haben: den vier Werten der Clean Code Developer Initiative. Diese Werte helfen uns, unsere Qualitätsansprüche im Alltag nicht aus den Augen zu verlieren.
Wandelbarkeit
Software wird, anders als physische Produkte, konstant verändert. Code ohne unnötige Komplexität ermöglicht das.
Korrektheit
Software muss tun, was von ihr erwartet wird. Mit der Entwicklung eines Features und Jahre nach dessen Abschluss.
Produktionseffizienz
Software, die nicht ausgerollt wird, ist wertlos. Dies widerspricht keinem Qualitätsversprechen, sondern ist eins.
Kontinuierliche Verbesserung
Ohne Reflexion keine Weiterentwicklung. Wir streben sie auf vielen Ebenen an: etwa im Code, im Prozess und in der Zusammenarbeit.
Wie wir Clean Development leben
Consulting
Wir entwickeln Software für Euch: iterativ, in hoher Qualität, mit Euren Herausforderungen im Fokus.
Training
Wir trainieren Engineering-Teams mit aktivierenden Formaten: echte Aufgaben, echter Code, echte Reflexion.
Health Checks
Wir schauen von außen auf Eure Delivery und benennen konkret, wo Praxis und Anspruch auseinanderfallen.
AI Consulting
Wir helfen Euch, die richtigen Fragen zu stellen, bevor Ihr die falschen Antworten baut.
Wie Clean Development entstanden ist
Das Clean Development Mindset ist nicht aus Büchern oder Konferenzen entstanden, sondern aus dem Alltag in konkreten Projekten.
Seinen Ursprung hat „Clean Development“ in einem Team, das aus zwei erfahrenen Softwareentwicklern und vier Bauingenieuren bestand. Die Ingenieure waren Menschen, die über die Jahre programmieren gelernt hatten, aber nie systematisch in Softwareentwicklung ausgebildet wurden. Der Auftrag war klar: Zeigen, wie gute Softwareentwicklung aussieht, und das Team dazu befähigen, sie zu leben.
Was einfach klingt, war in der Praxis eine echte Herausforderung. Denn Clean Code zu erklären ist das eine. Menschen dazu zu bringen, sauberen Code tatsächlich zu schreiben, iterativ, im Alltag und unter Druck, das ist etwas anderes. Wir mussten Wege finden, die funktionieren. Nicht als einmaliger Workshop, sondern als kontinuierlicher Prozess, der mit jeder Iteration weitergeführt wird.
Aus diesem Projekt in Kombination mit intensiver Beschäftigung mit Themen zur Agilität (Scrum, Kanban) und Clean Code (z. B. Ausbildung zum Clean Code Trainer) ist das Mindset entstanden, das wir heute konsequent in unsere Arbeit einbringen. Es wurde seitdem auf andere Teams übertragen und weiterentwickelt. Es ist kein fertiges Regelwerk, sondern eine Haltung, die sich in der Praxis bewährt hat. Clean Development baut auf Clean Code auf und erweitert ihn um Agilität, Kollaboration und den konsequenten Fokus auf das Kundenproblem.