Direkt zum Hauptbereich

Software Craftsmanship - The New Imperative

In meinem Beitrag "Der Software-Handwerker" habe ich das Buch "Software Craftsmanship - The New Imperative" von Pete McBreen schon kurz erwähnt, jetzt bin ich endlich auch dazu gekommen es zu lesen.




Im ersten Teil des Buches geht Pete auf die Ursprünge von Software Engineering ein und wofür es entworfen wurde. Mit einem kurzen Umweg über "good Enough Software" stellt er dann in Frage ob Software Engineering die richtige Metapher für die allgemeine Softwareentwicklung und die zumeist anzutreffende Anwendungsentwicklung ist.
Auf der Suche nach einer besseren Metapher zieht er dann parallelen zum Handwerk und vergleicht auch die Softwareentwicklung mit dem traditionellen Handwerk. Um dann im zweiten Teil weiter auf Software Craftsmanship einzugehen.

Gerade die Erläuterungen zum Software Engineering und dessen Geschichte hat mir noch mal die Augen geöffnet, woher manche seltsamen Anforderungen an zu erstellende Artefakte, einzuhaltende Prozesse oder auch Lerninhalte kommen. Das diese aber nur in einem bestimmten und seltenen Projektkonext Sinn machen wird dabei vergessen oder verschwiegen.

Im dritten Teil geht Pete dann auf die Auswirkungen von Software Crafstmanship nach seiner Vorstellung ein. Dabei beschreibt er sowohl die Beziehung zwischen Anwender und Craftsman als auch die positiven Auswirkungen dieser andersartigen Beziehung auf die Qualität der Software und des Kundennutzens.
Vieles davon kommt demjeniger, der sich heute mit der agilen Softwareentwicklung beschäftigt sicher bekannt vor. Neben einem kurzen Kapitel zum Management von Software Craftsman und der anderen Bedeutung des Managers in so einem Team geht er dann auf den Weg ein, den jemand beschreiten sollte um ein Meister im Software Handwerk zu werden.
Er stellt sich dort einen Weg wie bei dem traditionellen Handwerksberufen vom Lehrling über den Gesellen, welcher auch mit wechselnden Meistern arbeitet zum Meister vor.

Mit Blick auf das heutige Ausbildungssystem von Softwareentwicklern in Deutschland, kann ich dieses Vorgehen nur begrüßen, allerdings benötigt man in den Firmen auch die Strukturen dafür.

Im vierten Teil rückt McBreen dann Software Engineering an die richtige stelle in seinem System und stellt dar, wo es angebracht ist und auch was wir daraus lernen können.

Zum Schluß stellt Pete dann dar wie ein Projekt mit Software Craftsman gestaffed und durchgeführt werden könnte. Dabei geht er auch darauf ein wie man Software entwickelt, welche Wartbar ist und das auch in Zukunft.

Im ganzen Buch liegt immer wieder die Betonung auf der Verantwortung, welche ein Software Handwerksmeister für jede von ihm erstellte Software und für seine Lehrlinge und Kunden übernimmt.

Beim Lesen ist in mir die Vision eines Softwareunternehmens im Handwerkers sinne gewachsen und der Wunsch so zu arbeiten. Aber auch die Frage ob die Kunden bereit sind, sich da drauf einzulassen und für die Qualität ihren Preis zu zahlen.


So und da mich das Buch so inspiriert hat und ich die wertvollen Ideen nicht im Regal nicht verstauben lassen  möchte, habe ich es gerade in einen Briefumschlag gesteckt und auf die Reise geschickt...


Kommentare

  1. Schöne Zusammenfassung. Das FETT geschriebene Wort trifft es auf den Punkt. - Wollen wir wirklich Verantwortung tragen?

    AntwortenLöschen

Kommentar posten

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte. Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen ve rteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Mit dem Rücken am Tellerrand

Es ist gut auch mal über den Tellerrand zu schauen. Manchmal sind wir so in "unserer Welt" gefangen, dass wir den Rest gar nicht mehr wahr nehmen. Zum Beispiel muss ich mich immer wieder daran erinnern, dass nicht alle Menschen mindestens ein Smartphone haben. Oder das agile noch lange nicht Mainstream ist. Nur weil wir uns in einem Umfeld bewegen, in dem die Dinge so scheinen wie sie sind, heißt das noch lange nicht, dass dem auch so ist. Ein Typisches Beispiel für den Unterschied von Realität und Wahrnehmung der Realität. Aber auch um neuen Ideen eine Chance zu geben, welche scheinbar nicht funktionieren können, weil sie nicht in unsere Gedankenwelt passen ist es sinnvoll ab und an über den Tellerrand zu schauen. Heute habe ich noch einen Tweet, welcher darauf hinweist gesehen: Wenn uns das einmal bewusst geworden ist, dann neigen wir (oder zumindest geht es mir so) dazu möglichst oft über diesen Tellerrand zu schauen. Dabei kann es aber passieren, dass wir so

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität. Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus: Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit. Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist. (Was nun was bedingt, lass ich mal dahingestellt) Dadurch haben sich natürlich auch di