Software - ein lebendes Organismus

Software ist nie fertig. Trotzdem wird sie von den meisten Unternehmen so gepreist und behandelt. Wie du vermeidest, dein Budget zu verbrennen – und deine Nutzer so glücklich machst, dass sie es ihren Freunden weitererzählen.

Wusstest du, dass es in der Tech-Branche Software Architects gibt? Software Developers werden oft auch Builders oder Engineers genannt (Letzteres eher für erfahrenere Entwickler). Kein Zufall – die Parallelen zwischen Tech und klassischem Bauingenieurwesen sind verblüffend.

Was sind diese Parallelen und was können wir daraus lernen?

Parallelen: Bauingenieurwesen & Software Engineering

Wenn du ein Gebäude 🏗️ baust, musst du..

1. ..planen, was du bauen willst, Ressourcen einplanen usw.
2. ..eine Reihe externer Faktoren analysieren, um sicherzustellen, dass dein Projekt im gegebenen Kontext umsetzbar ist.
3. ..Innen- und Außengestaltung entwerfen – wie Räume aufgeteilt werden, wo Fenster hinkommen usw.
4. ..es dann tatsächlich von Grund auf bauen.
5. ..es in bestehende Infrastruktur integrieren – Internet, Stromnetz, Wasserleitungen – und prüfen, ob alles sicher und wie geplant ist.
6. ..das Gebäude warten, Teile ggf. erneuern oder bei wachsendem Bedarf erweitern.

Bei der Entwicklung von Software läuft es ähnlich ab – mit denselben Risiken und Herausforderungen.

In der Illustration siehst du den typischen Software-Lifecycle. Jedes Feature und jeder Meilenstein durchläuft diesen Zyklus. Er beginnt immer mit dem Plan, was gebaut werden soll, und endet mit der Wartung des aktuellen Feature-Sets.

Sobald Nutzer neue Feature-Requests stellen oder die Software zu veraltet ist, um am Markt zu bestehen, beginnt der Zyklus von vorn.

Keine Phase überspringen

Jeder Schritt im Software-Lifecycle ist entscheidend. Lass uns jeden einzeln durchgehen.

1. Die Planungsphase vernachlässigen

Würdest du ein Gebäude ohne Plan bauen? Wahrscheinlich nicht.

In dieser Phase werden Projektumfang, Ziele und Anforderungen des Kunden definiert und ein detaillierter Projektplan erstellt. Es gibt zwei grundlegende Ansätze für Software-Produkte: die Waterfall-Methode und Agile Project Management.

Der Waterfall-Ansatz verlangt, dass Software-Agentur und Kunde eine vollständige Liste aller Funktionalitäten festlegen und den kompletten Plan ausarbeiten, bevor die erste Zeile Code geschrieben wird. Das ist enorm herausfordernd – vor allem, weil sich Anforderungen im Prozess durch neues Markt-Feedback oder externe Faktoren ändern können.

Die meisten Software-Projekte nutzen den Agile-Ansatz, um im Budget zu bleiben und auf unvorhergesehene Herausforderungen reagieren zu können. Aber hier kommt der Haken: Viele Unternehmen nutzen Agile als Ausrede, gar nicht zu planen. Schau mal rein.

Agile als Ausrede zu nutzen, um einfach loszulegen ohne ordentliches Requirements-Engineering, wird dein Projekt mit Sicherheit killen. Die Entwickler werden höchstwahrscheinlich die dringlichsten Features falsch priorisieren. Im schlimmsten Fall funktioniert die Software gar nicht – oder mit erheblicher Verzögerung. Wenn du mit einem externen Software-Anbieter arbeitest, stell sicher, dass er einen kohärenten Prozess und ein sauberes Reporting hat.

Agile Project Management braucht trotzdem einen Plan. Der wesentliche Unterschied zur Waterfall-Methode: regelmäßige Feedback-Zyklen, Iterationen und eine tägliche, wöchentliche und zweiwöchentliche Neuausrichtung der Prioritäten.

"Wer nicht plant, plant zu scheitern."

2. Die Analysephase überspringen

In dieser Phase arbeitet die Software-Agentur mit allen Stakeholdern zusammen, um die spezifischen Features und Funktionalitäten zu definieren. Wer diese Phase überspringt, riskiert, dass gewünschte Features im geplanten Budget nicht umgesetzt werden.

Kurz gesagt: ein unzufriedener Kunde. Detaillierte Anforderungen helfen, das Projekt realistisch zu budgetieren, und sorgen für abgestimmte Erwartungen – entscheidend für langfristigen Projekterfolg.

3. Design auf die leichte Schulter nehmen

In Software gibt es 2 Arten von Design. Die erste betrifft, wie der Nutzer mit deiner Anwendung interagiert – einfache Wireframes, Mood-Boards und Mockups. Die besten und intuitivsten User Interfaces wurden bewusst so gestaltet, dass deine App so einfach wie möglich zu bedienen ist.

Wie in jedem Handwerk gilt: Wenn du etwas Großartiges willst, arbeite mit großartigen Leuten. Wenn du mit Mittelmaß leben kannst oder das Budget knapp ist, kann das natürlich ein akzeptabler Kompromiss für den Start sein.

Der zweite Typ ist Software Design. Alle Software-Komponenten aus der Vogelperspektive zu betrachten nennt sich Software Architecture.

Was bedeutet das konkret? Denk an Netflix. Die Software-Architektur von Netflix besteht aus Tausenden von Software-Services, die miteinander interagieren – für alles, was du auf Netflix tun kannst: einen neuen Account anlegen, einloggen, einen Film streamen, Zahlungen für dein Abo abwickeln und vieles mehr.

Jeder dieser Services wurde sorgfältig designed, um mit dem Nutzer-Ansturm umzugehen und sich bei unerwarteten Fehlern zu erholen. Ein beispielhaftes Software-Design für ein fiktives Feature findest du weiter unten.

Eine sauber architektierte Software entscheidet darüber, ob dein Produkt unwartbar und schwer erweiterbar wird. Betrachte gutes Software-Design als Investition in die Zukunft deines Projekts – um die berüchtigte Technical Debt zu vermeiden.

4. Die Implementierung überstürzen

In dieser Phase schreiben die Entwickler tatsächlich den Code. Im Rahmen des Agile-Prozesses sollten sie dem Kunden regelmäßig berichten und ihm die Möglichkeit geben, frühes Feedback zu geben. Das ermöglicht kurzfristige Anpassungen, die sonst erst viel später vorgenommen werden könnten. Dazu passend unser Blogartikel: "Warum Leute denken, Software-Agenturen seien schlecht"

5. Testing & Integration opfern

Die Testphase kostet Zeit und Ressourcen – wie jede Phase im Software-Lifecycle. Aber nichts bringt deine Software schneller zum Absturz als fehlende programmatische Tests. Dazu haben wir auch einen Blogpost: "Test Driven Development".

Neben dem Testen ist es entscheidend, dass deine Software ausreichend mit externen Services integriert ist, von denen deine Anwendung abhängt. Ein Web3-spezifisches Beispiel sind Oracles – das Einbinden von Off-Chain-Daten in Smart Contracts. Auch wenn das Teil früherer Phasen ist, sollte die Integration und das Testing auf der echten Mainnet-Blockchain ebenfalls getestet werden.

6. Maintenance vergessen

Software hat Abhängigkeiten – also Software, die nicht von deiner Agentur, sondern von Tausenden unabhängigen Entwicklern gebaut wurde. Dazu entwickelt sich deine eigene Anwendung weiter: Nutzer fordern neue Funktionen, entdecken Bugs, und Abhängigkeiten müssen aktualisiert werden.

Je besser deine Software-Agentur in den vorherigen Phasen gearbeitet hat – besonders bei Requirements Engineering und Software Design – desto einfacher und günstiger wird die Maintenance. Es gibt keine Software auf der Welt, die keine Wartung braucht – außer natürlich, sie nutzt niemand. Aber das wollen wir ja nicht. Manche Agenturen schrecken vor Maintenance zurück – stell sicher, dass dein Anbieter das mitträgt.