Buch-Rezension zu "The Pragmatic Programmer"

"The Pragmatic Programmer: From Journeyman to Master" von Andrew Hunt und David Thomas erschien 1999 bei Addison Wesley. Seit seinem Erscheinen ist dieses Buch viel zitiert worden und wird immer wieder als "Must-Read" aufgeführt. Bei all diesen positiven Kommentaren war ich sehr auf das Buch gespannt.

Das Buch ist sehr einfach zu lesen. Die Kapitel sind zwischen 5-10 Seiten und in sich abgeschlossen. Man kann somit problemlos im Buch hin und her springen, ohne etwas zu verpassen. Am Ende jedes Kapitels gibt es eine Liste mit weiterführenden Kapitel zu ähnlichen Themen.

Die behandelten Bereiche reichen vom verhindern von dupliziertem Code (DRY-Prinzip) bis hin zu pragmatischen Teams. Der Inhalt ist in diese 8 Teile gruppiert:

Eine pragmatische Philosophie
Ein pragmatischer Ansatz
Die Basis-Tools
Pragmatische Paranoia
Biegen oder Brechen
Während dem Programmieren
Vor dem Projekt
Pragmatische Projekte

"The cat ate my source code"

Diese kleine Abwandlung von "Mein Hund hat meine Hausaufgaben gefressen" soll verdeutlichen, dass jeder für seine Handlungen Verantwortung übernehmen muss. Der dazugehörige Tipp besagt, dass man Optionen anbieten soll, keine Ausreden. Dieser Tipp mag banal tönen, doch wie oft erlebt man das Gegenteil? Auch wenn man dies als gegeben erachtet, so ist es noch lange keine Selbstverständlichkeit. Anhand alltäglicher Situationen wird aufgezeigt, wie man diesen Tipp anwenden kann. Es wäre so einfach...

"Don't live with broken windows"

Die "Broken Windows Theory" der Polizei von New York wird ebenfalls kurz angesprochen. Die Theorie besagt, dass ein zerbrochenes Fenster in einem Haus eine Spirale der Verwahrlosung startet, die am Ende die Kriminalität im ganzen Viertel erhöhen kann. Wie dies? Das erste zerbrochene Fenster zeigt, dass sich niemand um das Haus kümmert. Mehr und mehr Fenster gehen kaputt und es beginnen grössere Sachbeschädigungen. So geht es dann weiter und weiter. Bei Code ist dies genauso. Kümmert sich niemand um die Qualität, beginnt der Code zu faulen. Wie auch bei den Fenstern ist es beim Code wichtig, sofort einzugreifen wenn die "Zerstörung" beginnt.

Prototypen und Tracer Bullets

In der Industrie ist klar, was ein Prototyp ist: ein für einen spezifischen Zweck funktionierendes Versuchsmodell. In der IT ist es meistens ein nicht wirklich funktionierendes Stück Software, das dennoch eingeführt wird. Muss dies wirklich so sein? Hunt und Thomas liefern eine bessere Definition. Um die 2 gegensätzlichen Verwendungen klar zu trennen, nutzen sie Prototypen und Tracer Bullets.

Ein Prototyp dient dazu, einen Sachverhalt zu klären und am Ende weggeworfen zu werden - also so wie in der Industrie. Die Tracer Bullets sollen dagegen verwendet werden, um mit minimalem Aufwand eine durchgängige Lösung zu erarbeiten. Die "Bullets" dienen als Grundlage für den Ausbau und werden eingeführt. Worin liegt nun der Vorteil? Wenn man unterschiedliche Dinge auch unterschiedlich benennt, hilft dies beim Verständnis. Mixt man die Begriffe nicht mehr durcheinander, wird klar was man erreichen will. Wird der Prototyp weggeworfen, braucht man sich nicht um Authentisierung und Logging zu kümmern. Weiss man aber, dass man an einer " Tracer Bullet" arbeitet, muss man diese Dinge von Anfang an berücksichtigen.

Dinge klar zu benennen ist wichtig, nicht nur bei diesen beiden Begriffen.

Fazit:

Das Buch bietet einige sehr passende Bilder um Sachverhalte zu beschreiben. So sei die Software-Entwicklung weniger mit der Konstruktion von Gebäuden zu vergleiche, als vielmehr mit Gartenarbeit. Software "wächst" und einige Produkte blühen, andere gehen direkt auf den Kompost. Auch wenn diese Bilder sehr gut die Idee vermitteln, so sind die Kapitel doch viel zu kurz und oberflächlich. Als Wegweiser mag dies genügen, doch um wirklich damit zu arbeiten fehlt einfach zu viel. Angesichts der unzähligen Referenzen auf dieses Buch bin ich ein wenig enttäuscht. Bei seinem Erscheinen muss das Buch neue Massstäbe gesetzt haben. Allerdings ist in den letzten 10 Jahren in diesem Bereich viel geschrieben worden. So finde ich Clean Code deutlich besser als The Pragmatic Programmer. Dieses Buch ist sicherlich lesenswert, aber ich würde es nicht als ein "Must Read" bezeichnen.

Zum Buch:

"The Pragmatic Programmer : From Journeyman to Master" von Andrew Hunt und David Thomas, 1999 Addison Wesley, ISBN 978-0-201-61622-4, 320 Seiten