Meistern Sie die Kunst der Softwareentwicklung

Veröffentlicht am: 03 September 2020

Autor:

Nieke Roos

Chefredakteur bei Bits&Chips

Lesen Sie mehr über Nieke Roos

Experte:

Robert Deckers EngD,PhD

Trainer

Lesen Sie mehr über Robert Deckers

Aktie

---

Angesichts der wachsenden Abhängigkeit von Software in einer zunehmend hochtechnisierten Welt ist es wichtiger denn je, als Softwarearchitekt die Kunst der Softwareentwicklung zu beherrschen. Die Ausbilder Robert Deckers und Bart Vanderbeke haben es sich zur Aufgabe gemacht, Entwickler zu Handwerkern zu machen.

„Ein Kollege erzählte mir einmal von einem seiner ehemaligen Projektmanager, der, als er merkte, dass die Schätzungen nicht mit seinem Zeitplan übereinstimmten, diese einfach halbierte, damit sie passten. Ich finde es unerhört, nicht nur, dass man so etwas als Projektmanager tut, sondern auch, dass Menschen so ein Verhalten dulden. Sie müssen nicht mit ihm schimpfen, aber Sie können den Mund aufmachen. Stattdessen beschweren sich am Ende des Projekts, wenn alles drunter und drüber gegangen ist, alle darüber, wie ihnen das passiert ist.“

Inspiriert von Google-Manager Fred Kofman und seinem Buch „Conscious business“ fordert Bart Vanderbeke Softwarearchitekten dazu auf, nicht länger das Opfer zu spielen. „Das ist inakzeptabel und ungesund“, sagt er. „Sie sind der Handwerker. Wenn Ihnen jemand sagt, dass Sie etwas in der Hälfte der Zeit erledigen oder das Design auslassen oder auf Überprüfungen verzichten sollen, sagen Sie Nein – und zwar konstruktiv. Softwarearchitekten sind rar, also sind Sie in einer komfortablen Position, ganz sicher nicht in der Position, sich selbst zu viktimisieren. Verstecken Sie sich nicht hinter dem ‚Management‘. Als Software-Handwerker sind Sie, um einen von Kofman geprägten Begriff zu verwenden, ‚bedingungslos verantwortlich‘ für alles, was Sie tun oder nicht tun.“

„Sie müssen bedingungslos Verantwortung übernehmen, was buchstäblich bedeutet, dass Sie die Fähigkeit haben müssen, zu reagieren – und zwar auf sinnvolle Weise“, sagt Bart Vanderbeke. Kredit: Bart Vanderbeke

Bei NXP in Leuven leitet Vanderbeke ein Team von fünfzehn Softwarearchitekten, die an 2,4-GHz-Funkanwendungen für die persönliche Gesundheit arbeiten – denken Sie an Hörgeräte, Kopfhörer und Ohrstöpsel. „Winzige Systeme mit winzigen Software-Stacks“, stellt er fest. „Aber selbst wenn Sie, wie wir, eine Codebasis von 100k oder 200k haben, ist Software-Handwerk von größter Bedeutung. Der Bau der Hardware dauert etwa ein Jahr, gefolgt von vielleicht fünf Jahren der Softwareentwicklung. Ich habe eine Reihe von Vorträgen entwickelt, um meinen Kollegen zu helfen, ihren inneren Handwerker zu finden.“

Die nicht-funktionale

Auch Robert Deckers ist ein Gleichgesinnter, der sich für die Verbesserung des Softwarehandwerks einsetzt, allerdings mit Schwerpunkt auf der Softwarearchitektur – „dem schwierigsten Kunststück des Fachs“, wie er es nennt. „Es fängt schon bei der Frage an: Was ist Softwarearchitektur? Sie können Hunderte von Büchern finden, die versuchen, eine Antwort zu geben. Einige sind zwar schlecht, schrecklich sogar, aber die meisten sind sinnvoll, aber sie erzählen alle eine andere Geschichte.“ Dies war einer der beiden Auslöser, die ihn dazu brachten, in das Thema einzutauchen, seine eigene Sichtweise zu entwickeln, sein eigenes Buch zu schreiben und seine Erkenntnisse an andere weiterzugeben.

Der zweite Auslöser war die Erkenntnis, dass man sich bei den traditionellen Methoden zu sehr auf die funktionalen Anforderungen konzentriert, während die nicht-funktionalen Anforderungen am schwierigsten in den Griff zu bekommen sind und daher die meiste Zeit in Anspruch nehmen. „Vor langer Zeit, als ich ein OOTI-Praktikant an der Technischen Universität Eindhoven war, war ich der Softwarearchitekt für einen Kopierer“, erinnert sich Deckers. „Nach zwei Monaten der Entwicklung begann das anomale Systemverhalten sein hässliches Haupt zu erheben und ich erkannte, dass wir auch eine Fehlerbehandlung vornehmen mussten – was für jemanden mit 20 Jahren Erfahrung offensichtlich war, war mir als Neuling nicht in den Sinn gekommen. Als wir fertig waren, stellte sich zu meiner großen Überraschung heraus, dass nicht weniger als 85 Prozent unseres Codes der Fehlerbehandlung dienten, so dass nur 15 Prozent unserer Bemühungen auf die Funktionalität konzentriert waren. Da habe ich zum ersten Mal erfahren, dass die wirkliche Herausforderung, die wirkliche Komplexität, im Nicht-Funktionalen liegt.“

Nach dem OOTI-Praktikum – dem PDEng Software Technology, wie es heute heißt – schärfte Deckers seinen Blick bei verschiedenen Unternehmen, darunter Philips Research und Sogeti. Seit 2013 leitet er Atom Free IT und coacht Unternehmen und ihre Architekten, indem er ihnen hilft, Architekturen zu erstellen, den Architekturprozess einzurichten und ihn zu verankern. In den letzten fünf Jahren hat er dies mit einem Promotionsprojekt an der Vrije Universiteit Amsterdam kombiniert, in dem er die kognitiven Aspekte des Systems Engineering erforscht.

Kommen Sie vorbereitet

Vanderbeke und Deckers sind die neuesten Zugänge zum Software- und Systemportfolio des High Tech Institute. Beide wollen Softwarearchitekten dabei helfen, ihre Arbeit besser zu machen – echte Handwerker zu werden. „Als Software-Handwerker wissen Sie, wie Sie Ihre Arbeit organisieren müssen, und Sie haben die Durchsetzungskraft, keine Kompromisse bei der Arbeitsweise einzugehen. Stattdessen streben Sie das Optimum an und berücksichtigen dabei die Einflussgrößen und Bedingungen. Sie tun die Dinge nicht, weil Ihnen jemand sagt, dass Sie es tun sollen, sondern weil Sie die Notwendigkeit verstehen, entscheiden Sie sich eigenständig dafür“, fasst Vanderbeke die Werte zusammen, die er in seinen Workshops vermitteln möchte.

Robert Deckers betont, wie wichtig es ist, sich auf die nicht-funktionalen Eigenschaften, also die Qualitätsattribute, zu konzentrieren.

Zu lernen, auf konstruktive Weise Nein zu sagen, ist ein zentrales Thema in Vanderbekes Unterricht. „Dazu müssen Sie vorbereitet sein. Wenn Sie gebeten werden, den Kurs eines Projekts zu bestimmen, müssen Sie mehrere Optionen parat haben, nicht bis ins kleinste Detail, aber so weit, dass Sie sie abwägen und eine fundierte Entscheidung treffen können. Wenn jemand zu Ihnen kommt und sagt, dass etwas in der Hälfte der Zeit erledigt werden kann, die Sie veranschlagt haben, und Sie die Fakten nicht kennen, kann er durchaus Recht haben – Sie können es nicht wissen. Wenn Sie wissen, wovon Sie sprechen, wird das nicht passieren. Sie können ein konstruktives Gespräch führen und werden vielleicht herausgefordert oder sogar überzeugt, aber Sie lassen sich nicht von unbegründeten Behauptungen überrumpeln. Jemand fragte mich einmal, ob wir die Dinge beschleunigen könnten, indem wir Abkürzungen nehmen. Daraufhin antwortete ich: ‚Die einzige Abkürzung, die Sie nehmen können, ist, bei den Spezifikationen zu sparen‘ – und das war das Ende der Diskussion.“

„Sie müssen bedingungslos Verantwortung übernehmen, was bedeutet, dass Sie die Fähigkeit haben müssen, zu reagieren – und zwar auf sinnvolle Weise“, fährt Vanderbeke fort. „In meinen Workshops verwende ich mehrere kleine Beispiele aus meiner täglichen Arbeit, um meinen Standpunkt zu verdeutlichen. Jemand, der vor der Verantwortung flieht, würde zum Beispiel sagen: ‚Ich habe meine Schätzung halbiert, weil mein Projektleiter es mir befohlen hat‘, während jemand, der die Verantwortung behält, ein ‚Spieler‘ im Sinne von Fred Kofman, sagen würde: ‚Ich wollte einen Streit mit meinem Projektleiter vermeiden, also habe ich nachgegeben‘. Ebenso würde ein Opfer sagen: ‚Ich mache Schätzungen, weil unser Prozess es verlangt‘, während ein Akteur sagen würde: ‚Ich möchte im Unternehmen bleiben, also wende ich den etablierten Prozess an‘. Wenn man sie auf diese kleinen Dinge aufmerksam macht, sind die Leute eher geneigt, ihr Verhalten zu korrigieren.“

Eine gute Architektur ist korrekt, konsistent und kommuniziert. Kredit: Robert Deckers

Weder Fisch noch Geflügel

In seinen Schulungskursen gibt Deckers seine Vorstellungen von guten Architekturen weiter. „Die Rolle der Architektur besteht darin, einen Lösungsansatz für die wichtigsten Systemeigenschaften zu bieten, die am schwierigsten zu realisieren sind. Als Systemarchitekt müssen Sie immer darauf achten, dass Sie auf eine Lösung hinarbeiten, eine Anleitung bieten und die Bedürfnisse Ihrer Stakeholder erfüllen, gleichzeitig aber auch ein Auge auf Dinge haben, die schief gehen könnten, wenn sie in der Architektur nicht berücksichtigt werden. Wenn Sie das nicht tun, sind Sie wahrscheinlich kein Architekt. Außerdem möchte ich, dass Softwarearchitekten verstehen, dass eine Architektur einen geschäftlichen Nutzen bieten muss und dass es möglich sein muss, das System innerhalb der jeweiligen Organisation zu bauen. Sie können nur dann ein effektiver Architekt sein, wenn Sie bereit sind, aus Ihrer technologischen Komfortzone herauszutreten.“

Laut Deckers ist eine gute Architektur korrekt, konsistent und kommuniziert. „Ein System muss insofern korrekt sein, als es die Belange der Stakeholder und die technische Umgebung berücksichtigen muss. Der Entwicklungsprozess muss konsistent sein. Bei Philips in Brügge wurde ich einmal Zeuge, wie ein Softwarearchitekt alle Vorbedingungen für alle von ihm programmierten Funktionen testete, weil er wollte, dass sein Code robust ist. Währenddessen verwendete ein Kollege in der Kabine neben ihm Zeiger, ohne etwas zu testen, weil er wollte, dass sein Code schnell ist. Zusammen in einem System ergibt das weder Fisch noch Huhn. Sie müssen sich über die wichtigsten Eigenschaften im Klaren sein – mein Rat: hängen Sie die fünf wichtigsten an die Wand. Und schließlich sollte eine Architektur so beschrieben werden, dass Sie sie mit den verschiedenen Beteiligten diskutieren können, was bedeutet, dass Sie für verschiedene Aspekte unterschiedliche Ansichten verwenden.“

Deckers betont, wie wichtig es ist, sich auf die nicht-funktionalen Eigenschaften zu konzentrieren, also auf die Qualitätsattribute. Er räumt ein, dass dies im Widerspruch zu dem beliebten Agile-Prinzip zu stehen scheint, so schnell wie möglich funktionierende Software zu liefern. „Ich werde oft gefragt: Wie kann man Agile und Architektur miteinander vereinbaren? Meine Antwort: Gar nicht. Es sind zwei unterschiedliche Denkweisen. Bei der Architektur geht es darum, zu schauen, bevor man springt, während man bei Agile einfach loslegt und auf der Grundlage des Feedbacks, das man erhält, Anpassungen vornimmt. Das ist für manche Unternehmen völlig in Ordnung, aber nicht für einen Kopierer oder einen medizinischen Scanner, bei denen Aspekte wie Zuverlässigkeit und Sicherheit von vornherein bekannt sind. Agile und Architektur lassen sich am ehesten miteinander vereinbaren, wenn man die Regeln verbiegt und die ersten Sprints den wichtigsten Anliegen widmet.“

Wenn Sie den Managementtrichter hinuntersteigen, verengt sich der Fokus und das Risiko für Konflikte wächst.

Bessere Entscheidungen

Bei der Zusammenarbeit kommt es zwangsläufig zu Reibereien. Ein Software-Handwerker braucht daher auch Werkzeuge zur Konfliktlösung. In seinen Workshops stellt Vanderbeke einen Managementtrichter vor, der gleichzeitig eine umgekehrte Konfliktpyramide ist. Die Pyramide verläuft in drei Ebenen: strategisch, taktisch und operativ – vom Was zum Wie. Wenn Sie den Trichter hinuntersteigen, verengt sich der Fokus und das Risiko eines Konflikts wächst. Wenn es tatsächlich zu einem Konflikt kommt, hilft es, den Trichter wieder hochzuklettern und ein gemeinsames Ziel oder Prinzip zu finden, um die Dinge zu beruhigen.

„Softwarearchitekten, die sich nicht einig sind, wie sie ein Problem angehen sollen, stecken oft in ihrer eigenen Lösung fest. Wenn man sie an die Hand nimmt und die Problemkriterien bespricht, wird die Pattsituation in der Regel beendet, da sie eine gemeinsame Basis finden“, erläutert Vanderbeke. „Es ist auch ein sehr nützliches Instrument für das Prozessmanagement. Wenn Sie sich in einer Besprechung befinden, die zu nichts führt, besinnen Sie sich auf die Gründe, warum die Besprechung überhaupt angesetzt wurde, und ein Ausweg ergibt sich fast von selbst.“

Mit dem Werkzeugkasten in der Hand sind Software-Ingenieure gut für das Handwerk gerüstet. Mit Deckers schließt Vanderbeke: „Es wäre schön, wenn sie bessere Entscheidungen treffen könnten. Dass sie autonomer arbeiten. Und gleichzeitig sollten sie mehr Spaß an dem haben, was sie tun.“

Dieser Artikel wurde von Nieke Roos geschrieben, dem technischen Redakteur von Bits&Chips.