Wenn wir über Rapid Prototyping sprechen, sprechen wir meistens nicht von einfachen „Papierprototypen“, sondern von komplexen Hardware-Software-Systemen – Systeme mit vielen beweglichen Teilen: Sensoren, Aktoren, CPUs, Interfaces usw. Um neue Produktideen zu erproben, schließen wir häufig erst einmal einfach zusammen, was nötig ist. Wenn in diesem Prozess eben schnell etwas Neues auf die Platine gelötet wurde, müssen auf der Softwareebene häufig Anpassungen an vielen Stellen gemacht werden, um die neue Funktionalität über ein User Interface nutzbar zu machen.
Oder wenn im Interface ein neues Feature hinzukommt, dass mit der Hardware kommunizieren soll, muss Code auf vielen Ebenen und den Kommunikationskanälen angepasst werden. Das führt naturgemäß zu ungewollten Fehlern, einem erhöhten Abstimmungsbedarf im Team und am Ende des Tages zu dem, was Entwickler_innen als Spaghetti-Code und Shotgun-Surgery kennen.
Betrachten wir diese Ebenen aus der Ferne, ergibt sich im Allgemeinen folgendes Bild:
Damit sich unsere Entwickler_innen darauf konzentrieren können, was sie implementieren und weniger wie sie das tun müssen, haben wir einen Regelsatz definiert, der eine einheitliche Architektur und eine Reduktion der kognitiven Belastung beim Programmieren ermöglicht.
Die Synthese solcher Regeln aus Erfahrungswerten ist in der Softwareentwicklung ein ganz natürlicher Prozess, der zu Zauberformeln wie KISS (Keep It Simple, Stupid), DRY (Don't Repeat Yourself), YAGNI (You Aren’t Gonna Need It), SOC (Separation of Concerns) oder SOLID geführt hat.
Unsere eigene Zauberformel für schnelle, unkomplizierte Hardware-Software-Entwicklung besteht aus folgendem Regelsatz:
[GET] /module/<module_name>/<request> [POST] /module/<module_name>/<command> [WS] /subscribe/<module_name>/<event> [WS] /unsubscribe/<module_name>/<event>
Frei nach Conways Gesetz ist diese Architektur auch ein Abbild unserer Teamstruktur, in der wir am Besten arbeiten. Diese Kombination aus Design Pattern, schlanken Code-Templates und einer agile Teamstruktur bietet uns eine optimale Grundlage für erfolgreiche Hardware-Software-Entwicklung.
Wir haben die Vorgehensweise zum Beispiel auch bei unserem Minimic angewandt. Durch das Framework haben wir in der Prototypen-Phase die Freiheit erlangt, mit vielen unterschiedlichen Hardware-Features und Darstellungsweisen zu experimentieren, um den idealen Fit zu finden:
Solche Experimente sind in frühen Entwicklungsphasen essentiell für die Validierung von Funktionalität und Use-Case. Durch die Anwendung unseres Frameworks konnten wir trotz dieses explorativen Vorgehens eine stabile Codequalität einhalten und nebenbei auch noch circa 60% des Codes für Commands, Requests und Signale reduzieren.
Die Hardware-Produkte unserer Kund_innen sind komplexe Anordnungen aus Sensorik, Aktorik, User-Interfaces und spezieller Algorithmik, die sich im Verlauf der Entwicklung durch neue Erkenntnisse ständig verändern. Es gilt den Spagat zwischen den Kundenbedürfnissen, einer idealen Infrastruktur und innovativer Funktionalität zu meistern. Hinzu kommt, dass exzellente Produkte sich dadurch auszeichnen, dass der hohe Grad an Komplexität den Nutzer_innen verborgen bleibt und die Schnittstelle zum Menschen durch eine intuitive Bedienung abgebildet wird. Dem müssen wir bereits in experimentellen Entwicklungs-Phasen entsprechend Rechnung tragen. Nur so lassen sich wertvolle Erkenntnisse auch früh gewinnen.
Die Definition von Best Practices, einfachen Bausteinen und bewährten Kommunikationskanälen ermöglicht es uns, schnell und dynamisch auf Änderungen zu reagieren. Eine einheitliche Sprachkonvention und der Fokus auf Einfachheit erleichtert die Diskussion über Vorgänge und Features, beschleunigt den Einstieg neuer Entwickler_innen in die Codebase und verringert den Aufwand in der Dokumentation.
Sie stehen vor ähnlichen Herausforderungen?