Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software [Englisch] [Gebundene Ausgabe]

Dieses Buch hat zwei Teile: einen ziemlich langweiligen und einen interessanten.

Der langweilige Teil kommt leider zuerst und ist etwa 230 Seiten lang. In ihm beschreibt der Autor seine Erfahrungen in dem Chandler-Software Projekt von der Motivation und den Anfängen bis - ja eben nicht bis zum Ende, weil Chandler auch nach Jahren noch lange kein 1.0 Release erreicht hat.
Rosenbergs Idee ist, zu dokumentieren - und zwar im Detail - wie die Entwicklung dieser Software vorging (nicht voran - voran geht es damit eben gerade nicht). Das es eine der vielen Never Ending Software Projects werden würde, ahnte weder Rosenberg noch einer der beteiligten Entwickler. Aber daß es so gekommen ist, gab Rosenberg die Chance, den Verlauf zu dokumentieren, zu kommentieren und zu analysieren.
Genau diese Analyse, die die Lektüre lohnenswert gemacht hätte, vermisst man über 230 Seiten lang.

Stattdessen erfahren wir, was in langen Diskussionssitzungen geredet und (nicht-) beschlossen worden ist, wie drei Leute mit fünf Meinungen zusammensitzen und es wochenlang nicht hinbekommen, auch nur eine Zeile Code zu schreiben. Wie nach und nach die Pragmatiker frustriert das Projekt verlassen und die Diskutierer bleiben, neue Leute kommen und mit neuen Ideen die Diskussionsrichtung ändern und alles bisher gewesene (oder noch immer nicht gewesene) in Frage stellen. Wie mitten im Projekt klar wird, daß wesentliche Designstrategien nicht bis zu Ende durchdacht worden sind und schließlich fallengelassen werden. So sollte Chandler zu Beginn ein reines Peer to Peer Projekt sein, daß auf jeden Fall ohne Server auskommen sollte, aber niemand hat sich überlegt, wie die einzelnen Computer sich ohne Server in vertretbarer Zeit finden sollen, um ihre Daten auszutauschen. So hatte ein Neuzugang ein leichtes Spiel, einen Server durchzusetzen, der dann natürlich nicht pragmatisch umgesetzt worden ist, sondern einen neuen Protokoll Standard implementieren mußte - frei nach dem Motto: wir schreiben keine Programme, sondern Frameworks.

Das so etwas nicht zum Ziel führen kann, ist ziemlich klar. Aber muß man das wirlich im Detail verfolgen? Nein. Das nervt einfach und irgendwann wird man wirklich ungeduldig. Das kennt man als erfahrener Entwickler wirklich zur Genüge: ein Management, das nicht managt, eine Gruppe von erfahrenen Entwicklern, die diskutiert aber keine Lösung findet, lange Diskussionen über das Design, das hinterher nicht funktioniert etc. pp. Aber muß man das auch noch nachlesen, obwohl man es jeden Tag selber hat? NEIN! Jedenfalls nicht, ohne eine intelligente Analyse, aus der man etwas lernen könnte.

Außerdem hat Rosenberg zeitweise ein Problem mit seiner Zielgruppe. Nach dem was ich hier bisher geschildert habe ist klar, daß dieses Buch nur für Software Profis lesbar ist. Selbst Leute, die gerne mal ein paar Zeilen zusammenhacken, werden sich langweilen, denn es geht zum 101ten Mal um die Probleme, die man lösen muß, um das Wachstum eines Softwareprojekts zu kontrollieren und es in vertretbarer Zeit zu einem vernünftigen Release zu bringen.
Dann bringt Rosenberg es allerdings zustande, seinen Lesern zu erklären, daß Python eine Scriptsprache ist - stutz (gibt es jemanden, der das noch nicht weiß?). Damit nicht genug: anschließend erzählt Rosenberg etwas ausführlicher, was der Unterschied zwischen einer Scriptsprache wie Python und einer kompilierten Sprache wie C ist. Puhhhhh!!!!!
Später das selbe mit dem GOTO Statement. Ist das wirklich irgend jemandem aus der Gruppe der erfahrenen Entwickler unbekannt? Und wissen wir nicht alle aus eigener Erfahrung, warum es Bockmist ist?

So gestresst legte ich das Buch nach 150 Seiten an die Seite und es war schon bei Amazon zum Wiederverkauf angeboten. Glücklicherweise nahm ich es dann doch noch mal zur Hand und gelangte bis Seite 230, wo die Analyse in Form einer kurzen Geschichte der Software Entwicklungsmethodik beginnt. Hier wird es interessanter, so interessant, daß ich das Buch jetzt wohl doch behalten werde. Rosenberg behandelt hier das Problem, daß die Hardware Entwicklung nach wie vor in etwa mit Moores Gesetz skaliert, die Software Entwicklung sich aber im Prinzip seit 40 Jahren nicht verändert hat und nicht schritthält: nach wie vor sitzen Individuen vor dem Bildschirm, und schreiben Code Zeile für Zeile. Nach wie vor geraten komplexe Projekte mit hoher Wahrscheinlichkeit in große Schwierigkeiten. Nach wie vor haben die meisten Manager keine Ahnung von Software und nach wie vor ist die Kommunikation unter den Entwicklern ein ungelöstes Problem. Ungelöst ist auch, daß mit zunehmender Zahl der Entwickler der Koordinierungsaufwand immer größer wird - ein Teil des Software Skalierungsproblems (Brooks Gesetz).

Eine Lösung dafür hat auch Rosenberg nicht. Aber er stellt einige Diskussionsbeiträge zusammen und darin besteht wohl der Wert dieses Buches. Er beschreibt die Anfänge der Programmierung, vom Lochkartenstapel zum strukturierten Programmieren und zur Objectorientierung. Vom schnellen Hack, ausgiebigen Designstudien, Design Pattern, Waterfall Model, Agile und Extreme Programming. Er erzählt von den Vor- und Nachteilen großer und kleiner Teams, immer gespickt mit Anekdoten, Beispielen und Zitaten der jeweiligen Advokaten der vorgestellten Methoden (alles Amerikaner natürlich). Man liest über Erfolge (Google) und Mißerfolge, Rosenberg fragt, ob Software Entwickler in ihrer Ausbildung Beispiele studieren, wie z.B. Literaturwissenschaftler Texte analysieren, um ihre Struktur zu verstehen (nein - Softwareleute machen das nicht, nirgendwo). Eine gute Idee. Es gibt genug große Open Source Software dafür (Emacs, JEdit, Linux, etc.). Rosenberg nennt auch Namen. Eine gute Quelle, um nach bestimmten Themen genauer zu recherchieren.

Allerdings muß jeder selber entscheiden, ob es sich lohnt, die 230 Seiten Einleitung durchzuhalten, um dann auf 125 Seiten durchaus spannende und anregende Ideen zu finden.
Rosenberg schreibt jedenfalls einen ganz gut lesbaren Stil, wenn man mal von der üblichen amerikanischen Ignoranz absieht, der er leider auch nicht entkommt: So fragt er zum Beispiel, weshalb man Software nicht so bauen kann, wie man Brücken baut (keineswegs eine neue Idee!). Nach guten Ingenieurrezepten, die immer funktionieren? Nun, seine Antwort: wir (WIR!) haben bereits 150 Jahre Erfahrung im Brückenbau, aber erst 50 Jahre in der Software Entwicklung. Kein Wunder, daß die Software da noch hinterher hinkt.
Ich weiß nicht, ob Rosenberg je in Europa war. Jedenfalls hat er sich bei seinem Rombesuch wohl mehr auf das Betrachten der Römerrinnen und aufs Eisschlecken konzentriert, als darauf, zu bemerken, daß er gerade über 2000 Jahre alte Brücken geht, die immer noch stehen.

Mit WIR meint er also uns Europäer wohl nicht. Dann folgern wir, daß wir also auch nicht zu seiner Zielgruppe gehören und folglich sparen wir uns besser das Geld für dieses Buch.

'Dreaming in Code' hörte sich für mich vielversprechend an, da es (wenn auch von einem nicht-technischen Standpunkt aus) die Entwicklung eines etwas größeren Softwareprojektes auf OpenSource-Basis beschreibt. Allerdings merkte ich schnell dass nicht nur der Autor sondern auch Teile der Projektentwickler anscheinend große Laberbacken sind die ihre Zeit gut damit verbringen das ganze bunte drumherum zu beachten und zu beschreiben. Es ist schwer genau festzumachen, aber je mehr ich las desto aggressiver wurde ich auf diesen Haufen anscheinend unkoordinierter Entwickler und wahrscheinlich noch mehr auf den Autor, der zu manchen Punkten immer wieder zurückkam so dass ich mir irgendwann das Ende des Buches herbei wünschte. Das Softwareprojekt ("Chandler") was in dem Buch beschrieben wird ist heute immer noch weit entfernt davon fertig zu sein und sieht weder zukunftsweisend noch vielversprechend aus (in meinen Augen). Leute die sich mit dem Gedanken befassen ein Buch über Softwareentwicklung im Allgemeinen zu lesen sollten sich hier lieber ein Projekt suchen von dem sie wissen dass es bisher halbwegs erfolgreich war.

Träumen in code? Das hört sich doch eigentlich "interessant" an. Aber dann erfährt man reichlichst über diverse Egos und lernt typische Fehler kennen die schon im "Mythical Man Month" behandelt wurden. Somit zementiert dieses Buch mehr oder minder die der Softwareerstellung zugewiesenen Probleme. Zu spät, zu teuer, zu viele Fehler.

Ziel war es wohl das Outlook aller outlooks zu schreiben, einen persönlichen "Planer". Wenn man sich das Resultat anschaut, dann fragt man sich schon, was soll das mit dem Träumen und was ist daran "transzendent"?

Es ist aber trotzdem interessant zu lesen, man sieht wie ein Projekt immer mehr in Verzug kommt, "Tag für Tag"....

I