Ingenieurprinzipien

Jedes Projekt beginnt mit dem Verstehen der Fachdomäne — physikalische Randbedingungen, operatives Vokabular, relevante Fehlermodi. Für einen BESS-Betreiber bedeutet das zu verstehen, was SOH-Degradation tatsächlich an Dispatch-Erlösen kostet, bevor eine einzige Abfrage geschrieben wird. Für einen Broadcaster bedeutet es zu verstehen, warum ein einziger verlorener Frame beim Ingest zu einem nicht konformen Lieferpaket führen kann.

Wir betrachten Domänenwissen nicht als etwas, das der Kunde bereitstellt und wir lediglich konsumieren. Wir investieren selbst darin: Wir lesen Normendokumente, führen Simulationen durch und stellen die Fragen, die banal erscheinen — denn das sind oft genau jene Fragen, die kostspielige Nacharbeiten in späten Projektphasen verhindern.

Die Konsequenz ist, dass unsere Schätzungen in der Realität der Domäne verankert sind und nicht auf optimistischen Analogien zu früheren Projekten beruhen. Wenn ein Scope Unsicherheiten enthält, benennen wir sie explizit, anstatt sie still in einen Lieferpuffer zu absorbieren.

Komplexe Systeme vereinfachen sich nicht von selbst — das erfordert gezielte Vereinfachung auf jeder Abstraktionsebene. Wir betrachten Architekturentscheidungen als Kommunikationsartefakte: Eine Komponentengrenze ist eine Aussage darüber, was sich unabhängig ändert; ein Datenmodell ist eine Aussage darüber, was das System wissen muss.

In der Praxis bedeutet das, dass wir dem Impuls widerstehen, zu Frameworks zu greifen, die Probleme lösen, die wir noch nicht haben. Wenn wir eine Abhängigkeit hinzufügen, dokumentieren wir, warum — und was es kosten würde, sie zu entfernen. Das Ziel ist eine Codebasis, in der der nächste Entwickler die Absicht aus der Struktur ablesen kann und nicht nur aus Kommentaren.

Benutzeroberflächen tragen dieselbe Verantwortung. Ein Dashboard, das für sein Verständnis eine Einweisung erfordert, wird in kritischen Momenten ignoriert. Wir gestalten für den Operator, der diese Zahlen um 2 Uhr morgens liest — nicht für die Demo-Umgebung.

Nicht sichtbarer Fortschritt erzeugt Unsicherheit, und Unsicherheit produziert voreilige Entscheidungen. Wir teilen Work-in-Progress — keine polierten Lieferobjekte, sondern funktionsfähige Prototypen und grobe Entwürfe, die dem Kunden ermöglichen, Feedback zu geben, bevor Investitionen verfestigt sind.

Wenn eine technische Entscheidung einen bedeutsamen Trade-off beinhaltet, legen wir diesen offen, anstatt nur eine Schlussfolgerung zu präsentieren. Wenn eine Scope-Annahme sich als falsch erweist, melden wir das sofort, anstatt die Lieferfrist stillschweigend anzupassen.

Das gilt auch für negative Befunde. Wenn sich eine von uns vorgeschlagene Technologie im Laufe des Projekts als ungeeignet herausstellt, sagen wir das offen. Die Kosten einer frühen Korrektur sind fast immer geringer als die Kosten einer späten.

Codequalität ist notwendig, aber nicht hinreichend. Ein gut getestetes Modul, das das falsche Problem löst oder sechs Wochen zu spät geliefert wird, hat keinen Wert geschaffen. Wir behandeln Lieferzuverlässigkeit als erstklassige Qualitätsmetrik — gleichrangig mit Testabdeckung und Performance-Benchmarks.

Wir nutzen CI/CD-Pipelines, Typsysteme und Linter nicht, weil sie modern sind, sondern weil sie die nächste Änderung günstiger machen. Wir schreiben Tests auf der Ebene, auf der sie am günstigsten zu warten sind und am wahrscheinlichsten echte Regressionen aufdecken. Wir profilieren vor dem Optimieren und optimieren vor dem Neuschreiben.

Wenn wir uns auf einen Liefertermin verpflichten, verpflichten wir uns auf den zugrunde liegenden Scope und die Annahmen, die diesen Termin realistisch machen. Ändern sich diese Annahmen, wird der Zeitplan neu verhandelt — und wir informieren Sie sofort.

Prototypen, die ersetzt werden sollen, werden es selten. Wenn wir etwas bauen, das in Produktion laufen wird, behandeln wir es vom ersten Commit an als Produktion: Umgebungsparität, strukturiertes Logging, Error Boundaries, graceful Degradation bei Teilausfall.

Für Echtzeitsysteme bedeutet das, über Backpressure nachzudenken, bevor die erste WebSocket-Verbindung steht. Für Dashboards, die Telemetrie im großen Maßstab verarbeiten, bedeutet es, das Datenmodell unter Last zu durchdenken, bevor der erste Chart gerendert wird. Für Streaming-Pipelines bedeutet es, bei Bitraten und Latenzen zu testen, die reale Betriebsbedingungen abbilden — nicht Demo-Bedingungen.

Wir bitten nicht um einen Aufräum-Sprint am Ende eines Projekts. Die Kosten dieses Sprints sind stets höher als verteilte Sorgfalt über den gesamten Projektverlauf, und das entstehende System ist weniger kohärent.

Ein abgeschlossenes Projekt ist kein Ergebnis — es ist ein Meilenstein. Das Ergebnis ist ein System, das weiterhin Wert schafft, während sich Anforderungen weiterentwickeln, der Maßstab sich ändert und sich die Domäne selbst wandelt. Wir gestalten von Anfang an für diese Trajektorie: Erweiterungspunkte, dokumentierte Entscheidungsbegründungen und eine Übergabe, die das Team des Kunden tatsächlich in die Lage versetzt, ohne uns weiterzumachen.

Wir bevorzugen Kunden, die uns als langfristigen Technologiepartner behandeln, nicht als Lieferanten. Nicht aus kommerziellen Gründen, sondern weil die Arbeit besser wird, wenn wir den Geschäftskontext tief genug verstehen, um Anforderungen in Frage zu stellen, die in zwölf Monaten Probleme verursachen werden.

Wenn ein Projekt endet, betrachten wir das akkumulierte Wissen als Eigentum des Kunden, nicht als unseres. Dokumentation, Architekturdiagramme und Runbooks sind Teil jeder Lieferung.