Über die Jahre habe ich immer wieder Softwerker erlebt, die ihr Handwerkszeug mal mehr, mal weniger beherrschen. Mit Handwerkszeug meine ich dabei nicht unbedingt die Design-Prinzipien und -Patterns, die uns guten Code schreiben lassen. Vielmehr meine ich hier die Werkzeuge, die uns all das ermöglichen. Wieso ist das so wichtig? Vielleicht hilft uns dabei eine Analogie weiter.

Mal angenommen, ich plane bei mir zu Hause ein neues Dach zu installieren. Für professionelle Unterstützung wende ich mich also an diverse Handwerker:innen in der Umgebung. Zwei Betriebe kommen dabei in die nähere Auswahl. Mit beiden vereinbare ich Termine für eine Auftragsklärung und einen Kostenvoranschlag.

Die Fachkraft des ersten Betriebes schlägt um 10 Uhr bei mir auf. Ich gehe mit der Person mein Anliegen durch, bekomme ein paar Ratschläge, die Person steigt nicht einmal aufs Dach und beschreibt den Hammer am Hosenbund als „Nagelreinmacher“. Ein Blick in das Dienstfahrzeug offenbart mir einen wild zusammengewürfelten Stapel an Werkzeugen. Auf meine Nachfrage hin, bekomme ich die Antwort, dass man die hin und wieder mal benötigt. Abschließend bitte ich um einen Kostenvoranschlag.

Die Fachkraft des zweiten Betriebes schlägt um 12 Uhr bei mir auf. Kurz beschreibe ich mein Anliegen, die Person vom Fach erbittet Zugang zum Dachboden und zum Dach, um sich ein Bild vom Zustand des Materials zu verschaffen, eröffnet mir drei Optionen, die ich wahrnehmen könnte mit entsprechenden Vor- und Nachteilen bezüglich der Wartungsanfälligkeit, Kosten und Lebensdauer. Kompetent wirkend zeigt mir die Person ihr Werkzeug, als ich mich danach erkundige und führt mich durch ein gut sortiertes Set an allerlei Werkzeugen mit entsprechender Erklärung, wann und warum das mal benötigt wird. Abschließend bitte ich um ein Variantenangebot und einen Kostenvoranschlag für die zwei mir sinnvoll erscheinenden Optionen.

Zwei Tage später liegen mir die Kostenvoranschläge beider Betriebe vor. Für wen würden Sie sich entscheiden?

Von der Analogie zur Software

Natürlich ist die Geschichte erfunden und ich habe keine Ahnung von den Tätigkeiten eines Dachdeckerbetriebes. Trotzdem ist ziemlich offensichtlich, dass die Fachkraft im zweiten Beispiel ihr Handwerk besser verstehen dürfte. Ob da etwas dran ist oder nicht, wissen wir nicht.

Im Vergleich dazu treffe ich immer wieder auf Personen und Teams in der Software-Entwicklung, die wenig Ahnung von ihrem Handwerkszeug haben. Allerdings betrifft die Diskussion rund um Werkzeuge in der Software-Entwicklung mehr als nur die IDE. In einer modernen IDE finden sich beispielsweise Menüeinträge für automatisierte Refaktorisierungen, die der Tool-Hersteller als sicher einstuft. Sicher bedeutet in dem Fall, dass so wenig wie möglich kaputt gehen dürfte. Natürlich finden sich dabei immer mal wieder Fehler, die wir als Menschen einbauen, wenn z.B. in einer tiefer liegenden gemeinsam genutzten Komponente eine Refaktorisierung getätigt wird, aber nicht alle Benutzer der Komponenten für die Refaktorisierung mit in der IDE geladen wurden, kann das Umbenennen einer Funktion schon mal zu Fehlern führen.

Wie meine Geschichte von dem Architekten zeigt, können auch scheinbar erfahrene Personen in der Software-Entwicklung schon mal ahnungslos von dem Repertoire, das ihnen zur Verfügung steht, sein. Der Architekt in meiner (realen) Geschichte hatte nur ein sehr oberflächliches Verständnis von Refaktorisierungen und war sich deswegen der Möglichkeiten nicht bewusst.

Teilweise scherzhaft warne ich heute schon vor dem Jahr 10.000 Problem. In meiner Vorstellung werden sich bis zum Jahr 10.000 kaum noch Personen damit auskennen, auf welcher Basis die eingesetzten Computer funktionieren, weil mit jeder Abstraktionsschicht immer mehr die Grundlagen in Vergessenheit geraten werden. Ein Beispiel gefällig? Ich frage mich, wie viele meiner Leser:innen wirklich wissen, welche Optimierungen im Code welche Konsequenzen im kompilierten Binärcode haben? Und ob sie das nur vermuten oder dafür sich wirklich den Binärcode am Ende ansehen? Bis zum Jahr 10.000 wird es vermutlich kaum noch Personen geben, die wissen, dass wir mal von zweistelligen Jahresrepräsentationen zu vierstelligen gehen mussten und ein ähnliches Problem von vier- auf fünfstellig existieren dürfte.

Über Werkzeuge hinaus

Bei Werkzeugen ist das „know-when“ wichtiger als das „know-how“, wie Jerry Weinberg einst feststellte. Das „know-when“ ist noch viel, viel relevanter, wenn wir über Design Patterns und -Prinzipien nachdenken. Diese Woche habe ich mir beispielsweise einmal die Mühe gemacht, die Paketierungs-Prinzipien von Uncle Bob Martin noch einmal nachzuschlagen. Zu den bekannteren Prinzipien gehören sicherlich die SOLID-Design-Prinzipien. Doch inwiefern Prinzipien wie Reuse-release Equivalence Principle (REP), Common-Reuse Principle (CRP) und Common-Closure Principle (CCP) zu mehr Kohäsion in den Paketen führen (oder was Kohäsion überhaupt ist und das wichtig ist) oder warum Acyclic Dependencies Principle (ADP), Stable-Dependencies Principle (SDP) und Stable-Abstractions Principle (SAP) zu geringerer Kopplung zwischen Paketen führen, ist wenigen Leuten bekannt. Kürzlich war ich überrascht, als ich ich feststellen musste, dass die Ursprünge dieser Prinzipien gar nicht aus dem Patterns, Principles and Practices (PPP)-Buch stammen, sondern noch viel, viel älter sind.

Als ich dann mir noch mal die Bedeutungen dahinter in Erinnerung rief, musste ich feststellen, dass diese Grundlagen vermutlich zu Ansätzen wie Ports und Adapter oder hexagonale Architektur geführt haben dürften. Auch wenn heutzutage Micro-Services in aller Munde sind, gibt es sicherlich basierend auf den Paketierungsprinzipien aus den Anfängen der objekt-orientierten Programmierung einiges zu entdecken, wie in einer Applikation bestenfalls aufgeteilt werden sollten. So kam es auch, dass ich bei meinem derzeitigen Kunden viele Ansätze gesehen habe, wie Fragestellungen rund um „wir haben Problem X immer wenn wir releasen wollen“ vermutlich mit einer Verletzung dieser Prinzipien zu tun haben dürften.

Etwas ähnliches lässt sich sicherlich über Praktiken wie test-getriebene Entwicklung, Ensemble-Programming oder Continuous Integration aufstellen. Softwerker, die ihr Handwerkszeug nicht kennen oder nicht beherrschen, sind sicherlich ähnlich kompetent wie der erste Betrieb in meiner fiktiven Eingangsgeschichte. Die Frage ist, was können wir tun, um die kompetenten Softwerker:innen von den weniger kompetenten unterscheiden zu können? Ich habe dazu Ideen, keine liefert aber eine immer gültige Antwort. Und, naja, bei der Auswahl von Handwerksbetrieben stellt sich schon mal die gleiche Problematik. Vielleicht sollten wir hier am ehesten auch auf die Reputationen von verlässlichen Quellen bauen. Für zusätzliche Ideen freue ich mich über entsprechende Kommentare an diesem Blogeintrag.