Nachhaltige Softwareentwicklung nicht der Rede wert

Clean Code im Fachbuchhandel ist kein Thema. Nachhaltige Softwareentwicklung scheint niemanden zu interessieren. Als symptomatischen Beleg dafür nehme ich die Regalmeter der Fachbuchhandlung Lehmann’s in Hamburg.

Fachbuchregalmeter

Lehmann’s wird sich mit dem Sortiment nach dem richten, was nachgefragt wird. Also ist der Inhalt der Regale ein Spiegel des Interesses in der Softwarebranche.

Zu sehen sind um die 2.200 Bücher. Deren Themen reichen von Linux über Office und Minecraft und Hacking bis zu C++, Agilität und Clean Code. Da ist für jeden etwas dabei, würde ich sagen.

Aber wo sind denn die Bücher über Clean Code als ausdrückliche Disziplin für nachhaltige Softwareentwicklung, also solche, die die Anforderung Wandelbarkeit erfüllt? Finden Sie sie? Tipp: Ich habe sie mit einem grünen Rahmen versehen.

Es sind 5 Bücher links im zweiten Regal ganz oben. Das sind knapp 2‰ des Gesamtangebots. OMG!

Wenn ich das Thema etwas weiter fasse und auch noch Bücher hinzunehme (rote Kästen), die sich mit einzelnen Praktiken des Clean Code Development auseinandersetzen (z.B. Continuous Integration) oder die Modularisierung als Grundlage für Wandelbarkeit behandeln (z.B. Entwurfsmuster, Softwarearchitektur, Domain Driven Design), dann kommen vielleicht nochmal 20 Bücher dazu. Insgesamt wären es also 25 von 2.200 oder 1,1%. OMG!

Nur 1% der Nachfrage dreht sich um Nachhaltigkeit!

Und wenn es 2% wären, würde das auch keinen großen Unterschied machen. 98% würden sich immer noch nicht dafür interessieren.

Was sagt das über unsere Branche aus?

Immerhin ist allen – ja, ich glaube, es sind wohl inzwischen alle – klar, dass es ein Nachhaltigkeitsproblem gibt. Der Begriffe dafür sind ja viele: brownfield, legacy code, big ball of mud…

Doch guidance sucht man für den Weg aus dieser Situation anscheinend nicht in der Literatur. Bei Minecraft hingegen (12 Bücher) oder Raspberry Pi (13 Bücher) glaubt man, Hilfe zu gebrauchen. Dabei ist beides im Verhältnis zur Nachhaltigkeit trivial. Denn bei beidem ist das Feedback, ob man es richtig oder falsch gemacht hat, unmittelbar. Clean Code hingegen oder eine zukünftigsfähige Softwarearchitektur… die zeigen sich nicht einfach so auf den ersten Blick. Die herzustellen bedarf auch anderer Gewohnheiten – sonst wäre das Drama ja nicht so groß – und also einiger mehr Anleitung und Übung.

Eigentlich müsste ich erschüttert sein. Aber ich hatte es schon geahnt. Ich war gewappnet, als ich in den Laden ging. Das Angebot an Büchern zur Nachhaltigkeit ist mager bis zur Vernachlässigbarkeit. Nicht mal das vollständige Angebot zu Clean Code oder auch – etwas hipper – Domain Driven Design oder Microservices ist vertreten. Es gibt mehr und auch lesenswerte(re) Bücher dazu. Dito bei der Softwarearchitektur.

Weder wird also nachgefragt, so dass sich ein Angebot im Regal lohnt. Noch findet eine Kuratierung der verfügbaren Titel statt. Das Personal im Laden sieht denn auch genauso aus wie das zur Schau gestellte Programm. Fachkompetenz bei den drei müden Gestalten hinterm Stresen gleich Null. Warum es den Laden noch gibt, ist mir ein Rätsel. (Früher war das mal anders. Da gab es noch engagierte Mitarbeiter, die sich um eine gute Auswahl bemüht haben. Wann war das zuletzt? Hm… vor 10 Jahren?) Es tut mir sehr leid, das sagen zu müssen. Ich mag ja Buchläden. Sehr gern sogar. Aber in dieser Form… gruselig.

Doch viel wichtiger ist eben, was die Ausahl über unsere Branche aussagt. Das real existierende Interesse liegt immer noch (oder schon wieder?) nicht bei der Nachhaltigkeit. Technology rulez!

Ich habe also nicht die Hoffnung, dass sich die vorherrschende Praxis hin zu sauberer(er) Entwicklung alsbald ändern wird. Microservices & Docker sind keine Rettungsboote für die Flucht aus dem legacy code für die Masse. Saubere Modularisierung, sauberer Entwurf diesseits aufwändiger Technologien jedoch, die könnten helfen. Nur muss man das wollen. Man muss sich darauf einlassen, Denken und Gewohnheiten zu verändern. Das kostet mehr Zeit. Aber es lohnt auch langfristig mehr, als die schnelle Fahrt in das nächste Komplexitätsdesaster.

Posted in Deutsche Beiträge.

6 Comments

  1. Hi Ralf,

    wieviele Bücher auf Deutsch und Englisch gibt es denn, die sich mit nachhaltiger Softwareentwicklung beschäftigen und welche sind Deiner Meinung nach davon wirklich lesenswert ?

    Peter

  2. Mir fallen grad diese Bücher zu Clean Code im engeren Sinne ein. Je mehr Sterne, für desto lesenswerter halte ich sie:

    *** The Art of Readable Code, Dustin Boswell
    *** Idea Flow, Janelle Klein (bei leanpub.com)
    *** Refactoring: Improving the Design of Existing Code, Martin Fowler

    ** Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin
    ** The Pragmatic Programmer. From Journeyman to Master, Andrew Hunt & Dave Thomas
    ** The Mikado Method, Ola Ellnestam & Daniel Brolund
    ** Working Effectively with Legacy Code, Michael Feathers
    ** Code Complete: A Practical Handbook of Software Construction, Steve McConnell

    * Growing Object-Oriented Software, Guided by Tests, Steve Freeman & Nat Pryce
    * Weniger schlecht programmieren, Kathrin Passig & Johannes Jander
    * The Clean Coder: A Code of Conduct for Professional Programmers, Robert C. Martin

  3. Hallo Ralf,

    der Artikel spricht mir aus der Seele. Leider geben sowohl wir Entwickler, als auch die Kunden sich oft mit halbfertige Lösungen zufrieden. Später wundert man sich dann wenn die kleinste Anforderung extrem teuer wird.

    Allerdings sehe ich selbst oft das Problem, dass Entwicklungsprojekte, die von Anfang an die Code Qualität extrem hoch halten, gerade in der Anfangsphase deutlich teurer sind. Ich versuche daher oft am Anfang sehr schnell was zu liefern und in späteren Phasen diese „Schulden“ wieder zurück zu zahlen. Bei kleinen Projekten mit überschaubarer Code Basis klappt das recht gut.

    Ich denke das Thema Qualität muss allgemein in unserer Branche präsenter gemacht werden – sowohl bei Entwicklern als auch bei Kunden.

  4. Hallo!
    Beim Lesen kam mir der folgende Gedanke: Vielleicht werden die Bücher nur auf andere Art und Weise vertrieben? Es ist ja möglich, dass der Clean Coder nicht in den Buchladen, sondern auf Amazon geht und gezielte Exemplare bestellt. Er muss nicht herumstöbern um etwas Interessantes zu finden, sondern weiß schon vorher was er kaufen will und was nicht. Und das geht im Internet leichter.

    Der Trend wird sich vermutlich auch im Internet abzeichnen, wenn auch nicht so extrem.
    Ansonsten ein echt guter Beitrag!

    • Natürlich werden auch Fachbücher auf andere Weise vertrieben: Versand durch amazon & Co, eBook. Dass jedoch Clean Code Bücher gezielter gekauft werden als Minecraft Bücher oder welche über SQL Server und deshalb nicht im Regal beim Fachbuchhandel stehen, glaube ich nicht.

      Außerdem geht es auch um die schiere Zahl der Titel: die ist viel geringer als die zu anderen Themen, z.B. NoSql. Dieser Unterschied ist schon ein Übelstand an sich.

  5. Na ja man sollte schon ein bisschen differenzieren.

    Einmal handelt es sich ja bei Clean Code nicht direkt um Grundlagen Bücher wie Einstieg in C# oder Ähnliches. Ich brauche da schon ein gewisses Erfahrung um mit dem Buch was anfangen zu können. Bei den Unis gibt es ca. 43% Abbrecher Quote im Bereich Informatik (1. google Ergebnis). Alleine da beleibt schon vieles auf der Strecke und bei „Hobby“ Entwickler wird es wohl ähnlich sein. Und meist sind ja Bücher im Bereich Clean Code, nicht direkt das 2. das man kauft sondern, da liegen noch ein paar dazwischen, so das man auf den Weg noch mehre Käufer verliert.

    Dann sollte man vielleicht auch noch mal Betrachten wie schnell sich die Inhalte Ändern. Clean Code (Martin) ist ca. 2008 raus gekommen und ich würde die Inhalte immer noch als aktuell Bezeichnen. Wenn ich dagegen Betracht wie sich das .Net Frameworke entwickelt hat, kann man Verstehen das es da mehr Bücher gibt.

    Quantität ist halt nicht gleich Qualität.

    Grundlegend finde ich aber das sich in den letzten 10 Jahren schon, ein bisschen was getan hat, auch dank deiner Mitwirkung.
    In den Foren wird meines Erachtens deutlich öfter das Thema Code Qualität angesprochen und auch Code Kritisiert, der ein Problem zwar löst aber nicht gut geschrieben ist.
    Bei meiner 1. Anstellung wurde mir noch „Verboten“ Unit Test zu schreiben, heute gehört es eigentlich schon zum Standard.

    Meines Erachtens liegt es mit daran, das wir so langsam einen Generationenwechsel bei den „Entscheidern“ bekommen, die dann eher mit den Prinzipien groß geworden sind.

    Gut es gibt immer noch Gerüchte, das Code Qualität in der Anfangsphase, teurer oder aufwändiger ist. Meines Erachtens und Erfahrung nach ist es nicht so.

    Um hier mal auf Alexanders Beispiel kurz einzugehen. „Ich versuche daher oft am Anfang sehr schnell was zu liefern und in späteren Phasen diese „Schulden“ wieder zurück zu zahlen. „

    Das meines Erachtens ein klassischer Fehler. Wenn ich meine Code Qualität kontinuierlich hoch halte. Beherrsche ich es recht schnell aus den FF und brauch bei vielen Sachen auch nicht mehr Groß drüber nachdenken. Wenn ich es Intervall weise mach muss ich mich immer umstellen. Das ist so Ähnlich wie mit dem Sport. 2 Wochen nicht machen und dann 2 Wochen Sport machen, ist deutlich schwerer als durchgehen zu trainieren.

Comments are closed.