Professionelle Softwareentwicklung - Basics

Motivation: Freitag Nachmittag

Letzten Freitag hatten das Team unseres Learning-Friday Projektes Hogarama ein Backlog Grooming in dem es die nächsten User-Stories besprach. Ich kam etwas später hinzu und bald entspann sich eine Diskussion über Feature Branches, Refactoring oder Neu-Schreiben und über Auslieferungen. Praktiken die ich für selbstverständlich hielt, wie ständiges Erhalten einer funktionierenden Version und Weiterentwicklung einer Anwendung in kleinen Schritten waren offenbar nicht unumstritten. Dies brachte mich zum Grübeln was wohl die Gründe für so unterschiedliche Auffassungen sein könnten. Hier eine mögliche Erklärung: Meine Auffassungen wurden durch professionelle Softwareentwicklung geprägt. Doch was ist professionelle Softwareentwicklung?

Theorem: Kosten und Wert

Wenn ich professionelle Softwareentwicklung beauftrage oder betreibe muss ich mir zumindest zwei Fragen stellen:

• Wann fallen Kosten an?
• Wann bekomme ich einen Gegenwert für meine Investition?

Kosten fallen an, sobald die Entwicklung beginnt, mit jeder Stunde die für das Projekt verwendet wird. Den Wert hingegen erhalte ich wenn ein Feature released, also dem Kunden zur Verfügung gestellt wird. Wert entsteht nicht durch Analyse, Kompilieren, Testen oder Präsentation vor dem Kunden. Nicht dass es nicht wichtig wäre, aber es entsteht kein Wert, höchstens Hoffnung auf zukünftigen Wert. Wenn wir also, als kleines Beispiel, 10 Entwickler zu einem Tagsatz von €1.000 in ein Projekt stecken und die brauchen 100 Tage (½ Jahr) um das erste Feature zum Kunden zu bringen, entstehen Kosten von €1.000.000 bevor ich einen Gegenwert bekomme. Das ist ein beträchtlicher Brocken gebundenes Kapital für den ich Zinsen bezahlen muss. Das ist aber nicht alles. In der Softwareentwicklung geht nicht immer alles gut und es besteht ein nicht unwesentliches Risiko, dass die Software nicht wie geplant funktioniert wenn sie ausgeliefert wird. Also brauchen wir eine Million Euro Risikokapital! Das erhöht die Zinsen, damit die Kosten und prägt die professionelle Softwareentwicklung.

Um die Kosten professioneller Softwareentwicklung möglichst gering zu halten, müssen wir daher das gebundene Kapital reduzieren und das Risiko verringern. Daher: „Release early, release often!“ Interessanterweise kommt die Open Source Gemeinde zum selben Schluss (siehe Eric S. Raymond; The Cathedral and the Basar) wenn auch von einem anderen Ausgangspunkt.

Korollar: Continuous Integration

Häufige Auslieferungen und kleine Inkremente führen zwangsläufig zu Automatisierung in Build, Test und Deployment, eine Praxis, die als CI/CD Eingang in Buzzwörterbuch gefunden hat.

Natürlich sind diese Überlegungen nichts Neues, die gesamte Agile Industrie basiert darauf. Heute macht beinahe jeder auf agil, bzw. das was er als agil definiert. Gelegentlich werden Definitionen so lange adaptiert bis vom ursprünglichen Gedanken nichts mehr sichtbar ist. Machen wir den Test? Sind folgende Aussagen in deiner agilen Organisation unumstritten?

•  „Done“ heißt „In Produktion“
• Feature Branching is Evil
• Wenn etwas „potentially shippable“ ist, gibt es keinen Grund es nicht auszuliefern

Jede diese Aussagen sind Anlass für ausführliche Diskussionen. Durchaus mit Recht. Man muss nicht unbedingt agil Software entwickeln. Aber wenn man es nicht tut, sollte man es auch nicht behaupten.

Disclaimer

Diese Überlegungen sind meine persönliche Meinung und repräsentieren nicht notwendigerweise die Meinung aller Mitarbeiter:innen.

Ja, ich habe Mathematik studiert.