Gute Software ist nicht nur Quellcode, sie erzählt eine Geschichte

Die Stadt am Fluss

Es war einmal eine kleine Stadt am Fluß, die vom Handel lebte. Morgens öffnete der Marktplatz mit allen Händlern, die mit Ihren Karren anreißten, während in der Mühle Bestellungen vorbereitet wurden, am Tor der Burg prüften Wachen die Lieferungen, und im Kornspeicher wurden Vorräte gezählt.

Es ist ein geschäftiges Treiben und jeder hatte seine Aufgabe und alle Funktionierte wie ein geöltes Urhwerk.

Doch eines Tages kam ein dichter Herbstnebel und die Karren stauten sich am Tor, auf dem Markt bildeten sich Schlangen und in der Mühle häuften sich halbfertige Säcke.

Und schon existiert ein Bild

Alleine mit der Erzählung wurde ein Bild geschaffen, über das wir beide jetzt sprechen und zusammen ausschmücken können. Dabei ist die Farbe der Burg nicht so wichtig, aber das eine Bug ein Burgtor hat steht außer Frage, das eine Burg Mauern braucht, einen Bergfried hat. Das müssen wir nicht mehr besprechen, es gibt auch Details die nicht Feststehen, aber wir haben schon vieles geklärt ohne das wir lange sprechen mussten.

So ist das für mich mit Software auch, es gibt gewisse Muster, die immer wiederkerend sind und bei denen Bereits Namen reichen um ein Konzept zu beschreiben und wie man es am besten löst.

Das beginnt mit der Namensfindung für Variables, in meinen Augen einer der schwereren Teile der Softwareentwicklung und geht über die Pfade und Ordner wie Dateien organisiert werden, bis hin zu Schnittstellen von Klassen und API's.

Bei einem Guten Entwickler erzählt der Quellcode genau eine Geschichte und erzeugt Bilder in meiner Fantasie.

Jetzt auf die Softwareentwicklung gemützt, kann der Satz des Baumeister der Stadt

"Wir müssen am Tor strenger prüfen."

Vieles Bedeuten und für jeden Beteiligten sogar etwas anderes.

Was in einem Satz steckt

Im Ratshaus gab es sofort Diskussionen.

Der Händler verstand: mehr Wartezeit. Die Schatzmeisterin verstand: höhere Kosten. Die Schreiberin aus dem Archiv verstand: mehr Rückfragen. Der Baumeister meinte aber etwas anderes.

Sein Satz enthielt unausgesprochenen Kontext:

• Welche Lieferungen grundsätzlich erlaubt sind.
• Welche Daten vollständig sein müssen, bevor die Stadt etwas verarbeitet.
• Welche Regeln für Ausnahmen gelten.
• Welche Folgen ein Fehler am Tor für Markt, Speicher und Abrechnung hat.

Genau dort beginnt für mich der Kern von Software-Entwicklung. Fachwörter sind keine Dekoration. Sie sind verdichtete Entscheidungen.

Die Parallele zur Software

Wenn wir jetzt das Wissen nehmen und unsere kleine Stadt mit Burg auf ein Software Projekt ummünzen, dann steht

• Die Stadt für das Projekt.
• Der Markt ist das Frontend.
• Die Mühle sind Formulare und Eingabeaufbereitung.
• Das Burgtor ist die API.
• Die Wachen sind Validierung und Autorisierung.
• Der Kornspeicher ist die Datenbank.
• Die Burgmauern die Firewall

Und schon wird das Bild etwas klarer, weil wir nur ein paar Begriffe "Bildern" zugeordnet haben. Genau das passiert in meinem Kopf als Entwickler beim Programmieren, ich sehe Muster, Gemeinsamkeiten, Unterschiede und Bedingungen und sich Ausschließende Regeln.

Wenn ein Entwickler sagt "Wir brauchen Idempotenz", meint er selten nur ein technisches Detail. Er meint, dass eine wiederholte Anfrage nicht zweimal abrechnen darf. Er meint Schutz vor doppelten Bestellungen. Er meint ruhigen Betrieb bei Retries und Netzwerkfehlern.

Wenn ein Entwickler sagt "Das ist ein kleiner Feld-Change", kann darin trotzdem viel stecken. API-Verträge, Migrationen, Reports, Berechtigungen, Historie, Supportprozesse.

Wenn ein Entwickler sagt "Das müssen wir in die Queue legen", meint er nicht Verzögerung um der Verzögerung willen. Er meint Entkopplung, Lastverteilung, Fehlertoleranz und ein stabileres Gesamtsystem.

Warum Teams trotzdem aneinander vorbeireden

In der Geschichte der Stadt passierte der eigentliche Fehler nicht am Tor. Er passierte im Verständnis.

Alle hörten dieselben Wörter, aber jeder hörte seine eigene Bedeutung. Der Händler hörte Umsatz. Die Wache hörte Risiko. Die Schreiberin hörte Aufwand. Und der Baumeister hörte Systemstabilität.

Das ist in Projekten genauso. Ein Satz wie "Wir machen das schnell" kann für Entwicklung, Vertrieb, Support und Geschäftsführung völlig unterschiedliche Bilder erzeugen. Und genau dort entstehen Reibung, Schleifen und Frust.

Zwei Arten von Kommunikation, ein Ziel

Ich sehe in Softwareprojekten immer zwei Kommunikationskanäle, die gleich wichtig sind.

• Kommunikation im Quellcode, sie richtet sich an Entwicklerinnen und Entwickler.
• Kommunikation zwischen allen Beteiligten, sie richtet sich an Produkt, Fachbereich, Support, Vertrieb und Management.

Beides erzeugt Bilder. Und Bilder entscheiden darüber, ob Menschen leicht oder schwer zusammenarbeiten.

Guter Code erzeugt bei Entwicklerinnen und Entwicklern klare innere Karten. Welche Verantwortung eine Klasse hat. Welche Daten an welcher Stelle gültig sein müssen. Wo Risiken liegen und wo nicht.

Gute Projektkommunikation macht dasselbe für alle anderen Rollen. Was ein "fertig" wirklich bedeutet. Wann ein Auftrag fachlich gültig ist. Welcher Kompromiss bewusst entschieden wurde. Welche Nebenwirkung akzeptiert wurde und welche nicht.

Wenn nur eine Seite klar spricht, bleibt das System unklar. Dann ist der Code vielleicht sauber, aber das Team stolpert trotzdem.

Gemeinsame Bilder sind ein Produktivitätsfaktor

Ich glaube nicht, dass wir bessere Zusammenarbeit nur mit mehr Meetings erreichen. Ich glaube, wir brauchen präzisere Sprache.

Nicht komplizierter, sondern klarer. Nicht mehr Worte, sondern die richtigen Worte. Nicht nur Tickets, sondern Bedeutung.

Drei Dinge helfen mir dabei in Projekten:

• Begriffe zuerst klären, bevor wir Lösungen bauen.
• Entscheidungen sichtbar machen, inklusive Grund und Folge.
• Mit Beispielen sprechen, weil Beispiele schneller Bilder erzeugen als Abstraktion.

Wenn wir das konsequent machen, passiert etwas Interessantes. Meetings werden kürzer. Rückfragen werden besser. Und Übergaben zwischen Rollen funktionieren ohne stille Übersetzungsarbeit.

Als konkretes Beispiel als Folgebeitrag passt dazu Die Stadt als Software-Landkarte.

Fazit

Gute Software ist für mich deshalb nicht nur guter Quellcode. Gute Software ist auch gute Verständigung zwischen allen Menschen, die daran arbeiten.

Quellcode ist Kommunikation für Entwickler. Projektkommunikation ist Kommunikation für das ganze System. Beides ist gleich wichtig, weil beides Bilder erzeugt.

Und wenn dieselben Bilder im Kopf entstehen, wird Zusammenarbeit leicht. Dann bauen wir nicht nur Features. Dann bauen wir gemeinsam ein System, das verstanden wird.