Methoden für komplexe Strukturen sind simpel – es erfordert lediglich Genialität sie zu verstehen

Standard

Unsere Welt wird immer komplizierter. Unsere täglichen Abläufe überfordern uns. Wir verstehen vor lauter „Bäumen“, die wir sehen und die ja so verschieden sind, den „Wald“ nicht mehr.

Nehmen wir zum Beispiel den Aufbau eines modernen Produktes bestehend aus mechanischen Komponenten, Elektronik und verschiedenen Softwaren. Früher ganz einfach. Gehäuse mit ein bisschen Mechanik, eine kleine Platine und eine Steuerungssoftware. Das war sehr lange so und hat sich natürlich in die Köpfe der Entwickler eingebrannt.

Ab und zu wird dann die Platine und die Software nochmal in einem anderen Gerät verwendet. Ok, dann muss man die Entwicklungstermine ein bisschen mehr koordinieren.

Aber nun, die Welt bricht um. Das digitale Zeitalter, wie wir es nennen, erreicht uns. Produkte werden wesentlich komplexer. Die Wiederverwendung der Komponenten steigt. Die Vielzahl der Teilprodukttypen steigt. Die Methodik etwas zu entwickeln bleibt aber auf dem Stand der letzten Jahre. Das „Antrainierte“ kann nicht so schnell im Kopf ersetzt werden.

Tooltechnisch kann die Lösung nur sein, einfachere Anwendungen als bisher für diese komplexen Strukturen zu schaffen. Das gemeinsame der Entwicklungsprozesse muss gefunden und darauf muss sich fokussiert werden. Egal um welche Baukomponente es sich handelt. Methodisch sind Mechanik und Software heutzutage gar nicht mehr weit entfernt. Mann muss es nur sehen wollen. Die Software hat sich aus dem Revier des „Künstlers“ in das des soliden Handwerkers und Entwicklers verschoben. Die Entwicklung der Mechanik ist agiler geworden. Zugegeben, es gibt Spezialitäten. Die sollte man dann aber separat abbilden. Eigene Tools dafür bauen. Die mit dem „großen Ganzen“ verknüpft werden.

Gut, ein Tool kann also im Prinzip für das Tracking von Mechanik, Elektronik, Software und Co. eingesetzt werden. Gleiche Methoden für alles. Gleiche Anwenderoberflächen für alles. Der datentechnische Inhalt unterscheidet sich natürlich, wie bisher auch. Querverknüpfungen werden komplexer. Das Suchen von Informationen wird mehr in die Richtung gehen, wie wir es aus dem Internet gewohnt sind. Die große Excelliste hat ausgedient, weil sie einfach nicht mehr breit genug ist, um auf die 3 Bildschirme nebeneinander zu passen. Landkarten des „Produktwaldes“ treten an die Stelle der bisherigen Suchlisten. „Detailzooms“ wie bei Google Maps die Streetviews treten an die Stelle von Gesamtübersichten. „Favoriten“ kennzeichnen das leichte Wiederfinden.

Ok, sind wir doch alles schon gewohnt, sagen Sie. Sicher? Auch in der Umgebung, in der wir uns, bestimmt von Excel und Office Anwendungen, selbstorganisierend seit 20 Jahren bewegen? Sicher nicht. Die Methode ist zwar standardisiert, aber in unserem Kopf muss sich einiges bewegen. Wir brauchen ein Bild von dem was wir tun, weil das letztendlich die allgemeine Methode nicht mehr 100% vermitteln kann. Hier beginnt für die altgedienten Recken die Herausforderung, ein kleines Stück Genialität ist hier gefragt. Neuanfänger haben an dieser Stelle weniger das Problem.

 

Advertisements

Gute Konzepte….

Standard
…sind einfache Konzepte.
Das möchte ich zunächst einfach mal so in den Raum stellen.
Wenn ein Projekt begonnen wird, werden zunächst einmal Anwendungsfälle analysiert und die Anforderungen aufgestellt. Danach sieht alles erst einmal ganz kompliziert aus. Da der Softwareingenieur ja ein Ingenieur ist, hat er sofort schon für jeden use case und jede Anforderung eine Lösung parat.
Damit ist’s passiert. Jeder Fall eine Lösung. Wenig Gemeinsamkeiten. Ein kompliziertes, umfangreiches Konzept ist entstanden. Entsteht gerne, wenn viele Köche sich viel wünschen dürfen und einer nur die Anforderungslisten mitschreibt.
Also sollte man das tunlichst sein lassen. Nach dem Aufschreiben, das möglichst ohne Gedanken an Realisierungsmöglichkeiten erfolgen sollte, müssen sich die Dinge erst mal setzen. Dann heißt es Ideen entwickeln und dann diese mit mindestens ein bis zwei anderen Personen, die ein bisschen Ahnung von dem Thema haben sollten, aber auch genug Abstand, zu diskutieren. Wieder setzen lassen. Diesen Prozess so lange iterativ wiederholen bis sich ein gutes Bauchgefühl eingestellt hat. Dann ist das Konzept einigermaßen tragfähig.
Letzte Prüfung: kann ich die Anwendungsfälle und Anforderungen mit möglichst wenig unterschiedlichen Methoden erschlagen? Hat der Anwender bezüglich use cases, die nur wenig variieren, so gut wie keine unterschiedliche Bedienung/Eingaben zu leisten?
Wenn ja, dann passt’s.

Software … ein gutes Stück Handwerk

Standard
Immer noch hat der Softwerker den Geruch des Nerds, des freien Künstlers, des Geistesarbeiters, desjenigen, der nie eine Aussage treffen wird, wann eine gestellte Aufgabe denn fertig sein wird.
Doch das hat sich gewandelt und wandelt sich immer weiter.
Softwerker sind immer mehr spezialisierte Handwerker, die ihre Werkzeuge gut kennen müssen, die die Bereiche verstehen müssen in denen SIe arbeiten, die eine Aufgabe selbständig abklären und einfach abarbeiten können müssen.
Der selbstverliebte Programmierer, der der sich nur um seinen Code kümmern und nicht die zu lösende Aufgabe verstehen will und damit keine Verantwortung für eine gute Anwenderlösung übernehmen will, der ist out.
Viele der in Programmen versteckten Fehler, viele Misserfolge von Softwareentwicklungen sind, meiner Meinung nach, darauf zurückzuführen, dass etwas spezifiziert und einfach auch so umgesetzt wurde, wie die einzelnen Realisierungshäppchen spezifiziert waren. Aber Spezifikateure machen auch Fehler, bedenken nicht alles und sehen manche Randaspekte nicht, die sich erst bei der eigentlichen Softwarerealisierung ergeben. An dieser Stelle ist der Softwerker gefordert. Wenn ihm etwas auffällt, das  er nicht versteht, hat er nachzufragen, abzuklären, eigenständig einen Vorschlag zu machen.
Ein Softwerker erfasst die Aufgabe. Beschreibt vor dem Tun seine Vorgehensweise, kommentiert seinen Code, verwendet eine Quellcodeversionierung, dokumentiert die Abläufe der entstandenen Funktion. Und, ganz wichtig, er ist kein einsamer Wolf, er kommuniziert mit dem Team und trifft Entscheidungen zusammen mit dem Team.
Zumindest bei einer Firmengröße wie der unsrigen, mit den komplexen Aufgabenstellungen, die wir haben, ist die Grundeinstellung, ein Handwerker, ein Softwareingenieur zu sein, unabdingbar für den Erfolg unserer Projekte.
Und so ist es nicht verwunderlich, dass es, ähnlich den Handwerkskammern, auch eine Vereinigung von handwerklich guten Softwerkern, die Softwerkskammer, gibt. https://www.softwerkskammer.org