Hogarama und “The Second System Effect”

Hohe Ziele

Hogarama hat als Client Teil einen Raspberry Pi, an dem man Sensoren und Pumpen anschließen kann. Der Client sendet dann Messwerte an eine OpenShift Instanz, wo sie gespeichert und ausgewertet werden können. Für eine massenweise Verwendung des Systems ist der Raspberry etwas zu schwergewichtig. Wir wollen echt “IoT” gehen:

• Es existieren kleine, unabhängige IoT-Einheiten, welche über die Cloud (Hogarama) miteinander kommunizieren (Sensor, Actor)
• Die IoT-Einheiten sind energiesparend und für lange Laufzeiten geeignet
• Die IoT-Einheiten besitzen ein Gehäuse im Gepardec-Style (3D-Druck)
• Es gibt eine Web-Adminseite und Übersicht der eigenen Pflanzen

Es sollten daher sowohl Client als auch Server und Admin-GUI massiv überarbeitet werden. Billiger, Besser, Schöner, Weltherrschaft!

Enthusiastischer Start

Die Begeisterung Anfang 2018 war groß. Wir wussten ja von unserer ersten Hogarama Implementierung, was wir besser machen konnten, was gut und was nicht so gut geklappt hat. Das ließen wir einfließen.

Wir setzen weiterhin auf Scrum, allerdings sollten noch kleinere Gruppen an einzelnen Features arbeiten. Die Learning Friday Situation ist nicht ganz einfach, da sehr wenig Zeit für die Arbeit am Projekt zur Verfügung steht. Um die Koordination einfacher zu machen sollten von den ca. 10 Personen immer zwei oder drei an einem Thema eng zusammenarbeiten. Aus firmenstrategischen Gründen ist immer auch standortübergreifende Zusammenarbeit im Projekt erwünscht, was uns später, zu Corona-Zeiten, zugute kam.

Wir hatten ein durchaus ansehnliches Team aus Expertinnen und Experten zusammengestellt:

• Scrum Mistress
• Architect
• User Experience Expert
• Frontend Developer
• Backend Developer

Offenbar hatten wir an alles gedacht. Was konnte damit schon schief gehen? Das Team stürzt sich in die Arbeit. Die Hardware-Gruppe beginnt mit Arduino-Laufzeittests und Sensor-Registrierung über das Handy. Die Backend-Entwickler bauen eine neue Postgres-Datenbank auf, bisher verwendeten wir nur Mongo-DB. Das Datenformat für die Sensordaten wurde angepasst und die Frontend-Gruppe beginnt ein neues Angular Frontend. Der User Experience Spezialist entwickelt raffinierte GUI Mockups für eine einmalige Benutzererfahrung.

Die Welt ist in Ordnung für unser kleines Hogarama.

Aber dann …

… holen typische Probleme der Softwareentwicklung unser kleines Hogarama Projekt ein. Wir haben zwar Batterietests gemacht, aber es findet sich niemand, der die Arduino-Software schreibt. Die Hardware-Gruppe dünnt sich aufgrund anderer Projekte stark aus. Andererseits benötigt die Sensorregistrierung einen funktionierenden Arduino. 

Dann haben wir eine tolle Backend-Software in einem eigenen Branch, die man in der Cloud nicht ausprobieren kann, da dafür die Installationsskripts fehlen. Außerdem sind die Schnittstellen für die Sensordaten nicht mehr kompatibel. Daher kann man sie auch nicht produktiv setzen, da die Sensoren und Pumpen über die neuen Arduinos noch nicht verwendbar sind.

Schließlich haben wir zwar tolle Mockups vom UX Experten, aber die sind so kompliziert, dass sie eigentlich kein Entwickler implementieren möchte und das Angular Frontend hat kein stabiles Backend zum Testen. Nach ca. einem Jahr Entwicklung gibt es noch kein einziges Feature in Produktion, die Hardware-Gruppe löst sich vollständig auf, der Branch kann nicht gemerged werden und die Motivation ist auf einem Tiefpunkt angelangt.

Aus dem Sumpf

Das Projekt ist gescheitert, das ist kaum zu bestreiten. Dennoch haben wir einige nützliche Funktionen entwickelt, die wegzuwerfen schade gewesen wäre. Wir schneiden daher alle Teile weg, die nicht zu retten sind. Das sind das fancy GUI und die Arduino Hardware. Dann integrieren wir das neue Admin Backend zur Verwaltung von Sensoren und Pumpen Stück für Stück in die bestehende Anwendung. Mit Hilfe eines kleinen Kompatibilitäts-Layers können wir auch das vorhandene SensordDatenformat verwenden.

Damit mussten wir bestehende Raspberry Clients nicht ändern. Als Admin-GUI nehmen wir ein weitgehend vorhandenes einfaches GUI, das sich die Entwickler für Testzwecke gebaut haben bis das “richtige” GUI fertig würde. Somit konnten wir doch noch mit relativ wenig Aufwand hilfreiche Funktionen für den typischen Hogarama-Benutzer (Technik Geek) bereitstellen.

Warum?

“Hogarama goes IoT” war ein internes Learning Friday Projekt. Wir haben auch technisch einiges gelernt, sei es Keycloak Integration in OpenShift und Angular (siehe Egors Keycloak Artikel) oder DB-Schemaverwaltung mit Flyway und JBoss. Alles in Allem war in unserem Fall das Scheitern bezüglich der Projektziele nicht schlimm. So ein Projektverlauf ist aber keine Seltenheit in der IT und es ist interessant zu hinterfragen wie es dazu kommt.

Frederick P. Brooks hat in seinem Klassiker “The Mythical Man Month” einem Phänomen ein Kapitel gewidmet, das zu unserem Scheitern beigetragen hat:

The Second System Effect

Bei der ersten Generation von Hogarama wussten wir nicht wie es geht, was auf uns zukommt. Wir haben es Stück für Stück entwickelt und getestet. Bei der zweiten Generation wollten wir alles richtig und besser machen. Und das sofort. Wir haben gedacht, jetzt wüssten wir, wie es geht. Alle Teile wurden neu designed. Over Engineering statt KISS (Keep It Simple and Stupid) Prinzip.

Kopplung und Kompatibilität

Besonders schädlich hat sich ausgewirkt, dass wir für “Hogarama goes IoT” gleich zu Beginn die Schnittstelle zwischen Sensor/Pumpe Komponente (Raspberry, Arduino) und Serverteil geändert haben. Dadurch war ein Test der einen Komponente nicht ohne die andere Komponente möglich oder in Produktion zu setzen. Die neuen Komponenten wurden unmittelbar eng gekoppelt, anstatt sich zu überlegen, ob es nicht möglich wäre vorübergehend kompatibel mit der originalen Lösung zu bleiben.

Dieses Verhalten sehe ich in vielen Projekten. Ist es Bequemlichkeit, Unwissenheit, Ignoranz oder vermeintliche Kostenersparnis? Will man sich nicht mehr mit “altem Schrott” auseinandersetzen? Projekt- oder Produktentwickler und -entwicklerinnen überlegen sich nicht ob oder wie es möglich wäre eine neue Version einer Software kompatibel mit der alten zu halten. Die mittelfristigen Auswirkungen werden nicht berücksichtigt oder als “unvermeidlich” hingenommen: 

• Automatische Tests brechen und müssen angepasst werden
• Komponenten müssen gleichzeitig entwickelt werden
• Komponenten müssen beim Deployment gleichzeitig migriert bzw. installiert werden

Lose Kopplung beschränkt sich nicht auf die Architektur der Komponenten, sondern umfasst auch den Entwicklungsprozess.

Work in Progress

Mit dem Thema Kopplung hängt auch zusammen an wie vielen Aufgaben das Team gleichzeitig arbeiten muss. Eine hohe Anzahl an unfertigen Teilen schadet dem Projekt. Es wird instabil und die Implementierungsgeschwindigkeit sinkt. Einzelne Aufgaben sollen möglichst schnell abgeschlossen werden. Unter “Abgeschlossen” verstehe ich “In Produktion”, siehe Artikel Professionelle Softwareentwicklung: Basics. Wenn sich daher die Architektur nicht um lose Kopplung kümmert und nicht auf Kompatibilität achtet, kommt das Projekt auch durch hohe “Work in Progress” ins Schwimmen.

Was haben wir gelernt?

Hogarama goes IoT hat uns wieder mal gezeigt, dass wir “den Mund nicht zu voll nehmen” und immer nur “einen Schritt vor den anderen” setzen sollen. In Wahrheit haben wie die Best Practices von “Continuous Integration” und “Release Often, Release Early” nicht befolgt. Jedes Projekt sollte darauf achten mit kleinen und kompatiblen Schritten dem Ziel zuzugehen.

Dafür ist vielleicht etwas mehr Gehirnschmalz nötig als einfach das alte Haus abzureißen und neu zu bauen. Jeder Entwickler, jede Entwicklerin sollte sich darin üben elastische und erweiterbare Software zu bauen, anstatt Glaspaläste, die beim ersten Hammerschlag in tausend Teile zerbersten.