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.

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.