Physik ist für meine Softwarearbeit weniger ein Fachgebiet, das ich direkt anwende, sondern eine Denkweise. Sie trainiert eine bestimmte Form von Vorsicht: Beobachtungen ernst nehmen, Modelle bauen, Annahmen offenlegen und Ergebnisse überprüfbar machen.

Das ist auch in der Softwareentwicklung wertvoll. Gute Software entsteht selten dadurch, dass man sofort die endgültige Lösung kennt. Sie entsteht, indem man ein nützliches Modell der fachlichen Realität baut und dieses Modell immer wieder gegen die Realität prüft.

Modelle sind nützlich, aber nie die Realität

In der Physik ist ein Modell kein Abbild der ganzen Welt. Es ist eine bewusste Vereinfachung. Es erklärt bestimmte Beobachtungen gut und lässt andere Aspekte weg. Genau diese Haltung hilft auch bei Softwarearchitektur und Domänenmodellen.

Ein Datenmodell, eine Schnittstelle oder eine Teststrategie ist ebenfalls eine Vereinfachung. Die entscheidende Frage ist nicht, ob das Modell vollständig ist. Die Frage ist, ob es für den aktuellen Zweck tragfähig ist und ob seine Grenzen bekannt sind.

Annahmen explizit machen

Viele technische Probleme entstehen nicht durch komplizierten Code, sondern durch unausgesprochene Annahmen. Welche Daten dürfen fehlen? Welche Reihenfolge von Ereignissen wird erwartet? Welche fachlichen Begriffe werden gleich verstanden? Welche Last, Latenz oder Genauigkeit ist wirklich relevant?

Eine wissenschaftliche Arbeitsweise zwingt dazu, solche Annahmen sichtbar zu machen. In Software kann das in Tests, ADRs, Schnittstellenverträgen, Monitoring oder klaren Fehlermodellen geschehen. Wichtig ist, dass Annahmen nicht nur im Kopf einzelner Personen existieren.

Unsicherheit ist kein Fehler

In der Physik ist Unsicherheit kein peinlicher Rest, den man versteckt. Sie ist Teil der Aussage. In Softwareprojekten wäre diese Haltung ebenfalls hilfreich: Risiken sollten benannt werden, bevor sie sich als Produktionsfehler melden.

Das bedeutet nicht, zögerlich zu arbeiten. Es bedeutet, Entscheidungen mit einem klaren Blick auf ihre Bedingungen zu treffen. Manche Dinge kann man berechnen, andere testen, andere beobachten. Und manche muss man bewusst als Risiko akzeptieren.

Tests als Experimente

Tests sind nicht nur Absicherung. Sie sind eine Form von Experiment. Ein guter Test formuliert eine Erwartung an ein System und prüft, ob diese Erwartung trägt. Je klarer die Erwartung ist, desto hilfreicher ist der Test.

Dieser Gedanke verbindet Unit-Tests, Integrationstests, Reviews, CI/CD und Observability. Sie alle erzeugen Feedback. Sie helfen, ein Modell zu bestätigen, zu korrigieren oder zu verwerfen. Ohne Feedback bleibt Architektur schnell eine Behauptung.

Fazit

Physik ist für mich kein dekorativer Hintergrund. Sie ist ein Denkwerkzeug: modellieren, Annahmen prüfen, Unsicherheit ernst nehmen und Feedback nutzen. In Softwareentwicklung führt diese Haltung zu Systemen, die nicht nur funktionieren, sondern verständlich, überprüfbar und veränderbar bleiben.