Was Kuchenbacken und Softwareentwicklung gemeinsam haben

Eine ungewöhnliche Analogie

Zugegeben, es scheint auf den ersten Blick wenig Schnittmengen zwischen einem Softwareprodukt und Backerzeugnissen zu geben. Dennoch erscheint gerade das Backen eines Kuchens in einer Konditorei genau richtig, die komplexen Abläufe in der Software-Entwicklung auf einen gemeinsamen Nenner dieser so scheinbar grundverschiedenen Fachdomänen herunterzubrechen.

Doch fangen wir ganz von vorne an. Wir möchten einen Kuchen backen: Der erste Gedanke daran läuft etwa so: die Zutaten werden besorgt und man fängt einfach an zu backen. Aber Moment! Es gibt verschiedene Rezepte, es gibt Hygienevorschriften und am Ende soll der Kuchen auch noch schmecken. Nicht zu vergessen, dass der Kuchen ja von einer Kundin oder einem Kunden bestellt wurde und daraus ein Qualitätsanspruch entsteht. Bei einem Lehrling mag der Fehler noch durch fehlende Erfahrung verschmerzbar sein und die Meisterin steht dafür gerade und bügelt diesen wieder aus, aber gerade die Meisterin hat den Anspruch – und dies erwarten letztlich auch die Geldgebenden –, dass der Kuchen eben meisterlich wird und sie sich dementsprechend mit nicht weniger zufriedengibt.

Und wo ist das Backrezept für Software?

In der Software-Entwicklung ist das nicht anders. Es gibt Bestimmungen zum Datenschutz, Sicherheitsaspekte und eben einen Qualitätsanspruch. Diesen Anspruch haben wohl alle professionell arbeitenden Erschaffenden (z. B. Ingenieure, Handwerker wie Architektinnen), welche – ob mit ihren Gedanken oder ihren Händen oder gar beidem – ein Produkt erzeugen, welches am Ende auch genutzt werden soll und für welches Geld über einen Tresen gewandert ist. Wo in der Konditorei ein Backrezept für Apfelkuchen vorhanden ist, führen im Software Development oft mehrere Wege zum Ziel. Aber stimmt das überhaupt? Es gibt die unterschiedlichsten Arten, einen Apfelkuchen zu backen und vermutlich noch mehr persönliche Interpretationen der eigenen Großmutter. Und wieder eine Gemeinsamkeit!

Manchmal gibt es in beiden Domänen Anforderungen oder Rezepte, die auf den ersten Blick sehr schwierig umsetzbar sind oder nicht gut harmonieren. Es ist keine gute Idee, eine Schwarzwälder Kirschtorte zu frittieren, aber man könnte die Torte mit einer karamellisierten Schicht Zucker dekorieren. Es ist äußerst bedenklich und obendrein rechtswidrig, die persönlichen Daten von Millionen von Menschen, ohne deren Zustimmung öffentlich im Internet zugänglich zu machen. Wenn sie sich aber freiwillig dafür anmelden und die Profile und Lebenswelten ihrer Mitmenschen nur nach Anfrage sehen können, dann ist das durchaus vertretbar.

Es gibt für fast jede Anfrage eine Lösung oder zumindest einen Gegenvorschlag und dafür ein passendes und bewährtes Rezept. Man muss nicht für jeden Kuchen oder jedes Softwareprodukt das Rad neu erfinden. Es lohnt sich oft auch in der Softwareentwicklung, auf Vorhandenem aufzubauen und keinen neuartigen Teig zu kreieren; kein gänzlich neues Framework für eine simple Website zu schreiben. Trotzdem bleiben es immer individuelle Anforderungen, die an Softwareentwickelnde gestellt werden. Kein Kuchen des Tages, keine Standardsoftware:

Wenn das Projekt in die Konzeption geht, ist es nicht anders als beim Planen des Entwurfs für die Hochzeitstorte. Die Zutatenliste mag sich an eine Vorstellung des Kunden und ein dadurch an sich gekoppeltes, grundsätzliches Rezept halten, letztlich ist es aber die Entscheidung der Konditoren und Konditorinnen, wie genau dieses Rezept umgesetzt wird. Es gibt ein Ziel und mehrere Wege führen dorthin.

Fangen wir an zu backen

Genau wie sich Milch durch pflanzliche Produkte austauschen lässt, lassen sich auch in der Softwareentwicklung Frameworks substituieren. Wir sprechen hier vom Softwaredesign, auch wenn der Begriff auf den ersten Blick irreführend klingt, ist dies im Nachhinein betrachtet doch logisch: Das Design und die Struktur des Programmquellcodes (nicht im ästhetischen Sinne) ist bestimmt durch die Entscheidungen, welche Zutaten hierfür verwendet werden und in welcher Form diese verarbeitet werden. Hierbei orientieren wir uns an grundlegenden Prinzipien, um den Code strukturiert und sauber zu halten, damit das „Software-Backen“ ordentlich und nachvollziehbar bleibt.

Auf einer höheren Ebene spricht man dann wiederum von einer Architektur und die damit zusammenhängenden strategischen Entscheidungen: Welche Systeme arbeiten zusammen und vor allem: Warum? Diese Entscheidungen müssen begründet und nachvollziehbar für alle sein, am besten noch festgehalten in „Architectural Decision Records“ (ADR).

Die Konditormeisterin hat sich auf Grundlage des Auftrags dazu entschieden, dass es mehrere flache Backbleche mit dem gleichen Kuchen gibt. Es hätte auch ein gigantisches Backblech sein können, allerdings ist dieses nur schwer zu transportieren. Und hier kommt auch das Team ins Spiel.

Das Team arbeitet Hand in Hand, um die Größe des Auftrags zu bewältigen. Arbeitsprozessoptimierungssysteme (Stichwort: SCRUM) helfen hier, den Überblick zu bewahren und die Aufgaben zu atomisieren, klar zu verteilen und schließlich zu erfüllen. Entwickelnde und Designende, die ihre Arbeit meisterlich bewerkstelligen, sind teuer, aber aus gutem Grund: Die Qualität stimmt! Qualität gelingt aber nicht, wenn das Zeitfenster zu knapp ist. Eine exzellente Hochzeitstorte ist weit im Voraus der Hochzeit geplant und abgestimmt. Es gab genügend Zeit, die Torte zu entwerfen, sich Feedback einzuholen und selbstverständlich zu backen. Die Konditormeisterin hat sich davon überzeugt, dass die Qualitätsstandards erfüllt worden sind und sie sich nicht mit weniger zufrieden geben würde, bevor sie die Torte übergibt. Das ist bei meisterlich entwickelter Software nicht anders: Gut Ding will Weile haben. Und wenn es doch einmal schneller gehen muss, dann müssen Kompromisse in Bezug auf die Funktionalität gefunden werden, aber niemals Abstriche bei der Qualität oder der Sicherheit! Software soll funktionieren, aber auch sicher sein, auch wenn Feature X vielleicht erst im nächsten Sprint hinzukommt. Und d er Kuchen soll schmecken und bekömmlich sein, auch wenn man aufgrund des Zeitmangels einige Abstriche bei der Dekoration in Kauf nehmen musste.

Auch aus Kundschaftssicht muss sich diese Frage gestellt werden: Möchte ich etwas Günstiges, das schnell zusammengehackt wurde oder ein Spitzenprodukt, das durch testgetriebene Entwicklung, Feedbackschleifen, einer soliden Infrastruktur robust und für die Anwendenden in der UX angenehm zu verwenden ist? Ratsam ist es hierbei, sich früh bewusst zu machen, welche Aufgabe das Produkt haben wird. Um die Analogie wieder aufzugreifen: Spätestens, wenn man täglich Kuchen in die Cafeteria geliefert bekommt und eine Belegschaft zufriedenstellen muss, möchte man, dass der Kuchen auch schmeckt. Hier und dort lässt sich dank des agilen Kontexts noch etwas schrauben, aber letztlich sollte ein gewisser Scope des Projekts abgegrenzt sein. Ein MVP also.

Wird nach dem Backen nur noch die Küche aufgeräumt?

Damit endet der Prozess jedoch nicht. Gute Software altert auch. Die Erfahrungen aus dem gestrigen Produkt fließen schon in den Release von morgen ein und das Feedback des heutigen ist mindestens genauso wichtig. So lässt sich auf Dauer ein Softwareprodukt nutzen, dass sich ständig an geänderte Umstände und Anforderungen anpassen kann. Das gilt selbstverständlich auch für die Konditorei.  

Auch dort wird sich ständig angepasst und weiterentwickelt. Ein Konditor muss hin und wieder vollkommen fremde Rezepte ausprobieren, um kreativ zu bleiben und die Erkenntnisse für das Alltagsgeschäft der Apfelkuchen und Hochzeitstorten nutzen zu können. Die kreative Freiheit, die hierbei gegeben ist, kommt mit der Profession an sich und birgt auch die Verantwortung, die zur Verfügung stehenden Werkzeuge bei Bedarf zu nutzen. Und so wird die Konditorei das Feedback der Kundschaft – sei es vom Apfelkuchen oder der Hochzeitstorte – auch für den nächsten Auftrag nutzen. Und das ist auch beim Erstellen von Software nicht anders.

Zugegeben, der Vergleich lässt sich nicht 1:1 transferieren. Alles in allem geht es auch nicht um Kuchen, denn man hätte genauso gut ein Metall- oder Holzerzeugnis aus einer Schreinerei hierfür verwenden können. Es geht um das Handwerk an sich, dessen Meisterschaft in der Profession sich direkt auf das Produkt auswirkt. So ist es eben auch der Qualitätsanspruch von BRICKMAKERS, den wir täglich beweisen und uns in unserem Handwerk am Herzen liegt. Schließlich sollte man beim Ausüben einer Tätigkeit – egal ob als Meisterin, Geselle oder Lehrling – am Ende des Projekts mit Stolz erfüllt sein und das Erzeugnis guten Gewissens an die Kundschaft übergeben.