Don’t memorize, understand: Memorizing stuff is hard and mostly useless, when you actually want to apply your knowledge. Of course understanding stuff isn’t much easier, but it uses much less brain capacity once done, and you can apply your knowledge in new areas as well. So the question is: how do you achieve understanding? Here are my recommendations:

Modify: When you read or hear something, think about what might happen if you change it a little. Let’s say you are learning a programming language, e.g. Java. One of the first things you’ll get taught is how to write a hello world program. Take that program and apply small changes: Add a semicolon on various places; Remove a semicolon; Change names and literals; Change the order of lines and so on. Most of these changes will result in a compilation failure. That’s great, because now you experience, what kind of mistakes cause which kind of exception. For example you will see that a program needs a main method and you’ll see what the exception looks like, when there is no such method.

Compare: Compare the stuff you are learning with stuff you already know. This is extremely important. If you have nothing to compare with, all you can do is memorizing. This becomes extremely obvious, when kindergarten kids ask questions about quantum mechanics or software development. For example my son asked me what all these curly braces are for when programming. Trust me, that’s hard to explain to a five year old. On the other hand when I learned C, I already knew among others Pascal, so I immediately thought: ‘Ok, curly braces are like begin/end, just shorter’. Often it helps to compare to something, even though the comparison falls apart when looking close enough. Consider for example  the various analogies for software development. In the end they are all wrong, but still they are helpful, especially once you understand which parts of a comparison work and which don’t

Build a mental model: Chances are when learning something new, you won’t understand every detail. Still build a model about what is going on, and about the purpose of different pieces.

Verify (or falsify) your model: By experimentation, try to verify your model. This will force you to modify your model, until you will have a pretty decent one.

Teach your new knowledge: When preparing a training, a presentation or a blog post about something, it forces you to really think  through it, thus deepening your understanding.

Practice: All the stuff should happen during actual experimentation, not just in your head.

The last four steps are all about what you do with knowledge heading your way. So the obvious next question is: “How do you direct knowledge your way?”

Read Books for in Depth Information: I  love the Internet, and you’ll find almost any information somewhere. But lot’s of it are just little pieces of wisdom (or stupidity) . The author of a good  book will put much more thought into his writing then the average blog author.

Read Alternative Sources: Once you have a basic understanding of something read additional sources, for example blogs, Wikipedia articles (possibly in different languages), other books, scientific publications. This serves as repetition, but also as a source of various opinion.

Reread your Sources: Especially with books I use little post-it index markers to mark interesting pieces and some time after I finished a book, I’ll use these markers to go through the interesting pieces again.

Provide yourself with a constant stream of information about the topic of interest: A good way for doing this is to subscribe to newsletters, or relevant blogs, or following relevant people on twitter. Of course paper based magazines work just as well. It will cause you to rethink the topic over and over again, thus triggering repetition.

Keep a list of things you don’t understand yet and work on reducing that list: When I hear a term which I don’t know, but which might be interesting for me, I put down a note and look it up on google, wikipedia, or whatever seems appropriate asap. Just as the two points before it is a form of repetition, but it also builds a network of different but related terms, which helps in building comparisons.

Stop reading when it doesn’t add value: This is a thing which I had problems with. Once I started a book, I had the habit of finishing it. Same for articles. This is stupid and a wast of time. There are so many great books, articles and sources of information out there. You won’t be able to read them all. So I consider it a critical thing to identify stuff that doesn’t add value for you and skip it. If that means skipping the rest of a 600 pages book after reading the table of content, that’s great. By the way: you absolutely should go through the table of content and the text on a back side of a book, in order to get an impression what the book is all about.

And finally there is the aspect of your environment, which largely affects your capability of learning.

Motivate yourself: Why do little boys know so much about dinosaurs, often including all the difficult names? Yet grown ups have a hard time distinguishing a Brontosaurus from a Pteranodon. They find dinosaurs cool. They are big, they are strong, and the boys soon realize, they know more about them than their parents. That is pure motivation. So find out for yourself why you want to learn something. What will be better, easier or more fun in your life once you grappled that new knowledge? Promise yourself a little gift once you are done with a piece of your learning. For tiny steps the gift should be tiny. For me such a little gift often is a tweet, publishing my progress to the world.

Make yourself comfortable: Find a spot which you can easily access, and which offers everything you need for learning. This might include: Something to eat, to drink, music, a door to close, a comfy chair, a window with a nice view.

Use your knowledge: In my opinion nothing is so gratifying and motivating as applying new knowledge. And again, you’ll find the limits of your understanding, giving you a chance to push these limits outward.

Know your preferred time for learning: There are certain times in the day where I’m more able to do mentally challenging stuff. For me the best time is the early morning. Your mileage my vary, but I am pretty sure everybody has such a time and should know it.

So these are my study techniques. What are yours?

1. Gather information. Make sure you have reliable information about
   • Which application has a problem
   • What are the steps to reproduce the problem
   • The version of the application
   • Does it happen only to specific users, specific machines or to everyone everywhere
   • When did the problem start to happen

   The important part is the reliable part. Users are known to have a completely different perspective on applications. I had users swearing there was only one message box although there where two (they didn’t understand the content of the second, but it was the information needed by the developer). The last point is a difficult one. In many cases you will hear things like “Oh it just started today. Everything was fine the last two months” Just to find out, nobody had used that feature before. Probably the best source of information is a clean logging trail.

2. Give a first estimate. Yes, that early. Most of the reasonable users are pretty happy with something like: I give you an update in half an hour. They might not be just as happy with: “I think I can look into this next month” but if this is the case it is at least fair to let them know. If the problem is urgent and the resolution time is long a workaround might be needed. Check your estimate every now and then. If you realize that you can’t deliver on your estimate for whatever reason, let the user know.
3. Make sure the bug is a bug and not a butterfly. Although users sometimes have a different oppinion: Software can’t do what they wish. It can only do what they say. So many times the behavior now classified as a bug was considered a feature when it was specified. If this is the case let the user know, give him a reason why it is specified this way, and inform him about the chances to change it.
4. Reproduce the problem. If possible reproduce it on your machine.
5. Simplify and automate. Often the procedure to reproduce a problem is long, but often some steps aren’t necessary. By finding these step you’ll gather information about what influences the problem and what not. If possible you should automate the reproduction of the problem using a test case. With a serious bug you will execute the steps for reproducing the problem a lot. If this takes 2 minutes, spending 2 hours reproducing the problem with a testcase might easily payoff before the bug is fixed. But even if it doesn’t pay off immediatly you will have another test case in your Test Suite.
6. Now we finally start working on the buggy code. Find the place where the state of the application is not the way it is intended to be. Often this will be just before a NullPointerException is thrown, but it might be a line, where an event should get fired but doesn’t, or where the variable Pi is supposed to be equal to 4 but actually holds the value 2. Add debugging output to show the problem.
7. Find a place shortly before the point found in step 6 where everything is ok. Add debugging output to show the absence of the problem.
8. Find a place between the spots identified in step 6 and 7. Check if the problem is present at that spot. Document it with a debugging statement.
9. Repeat from beginning from step 6 until you find the actual faulty line in the application.
10. Fix it.
11. Test it (should be easy with the automated test from step 5).
12. Let the user know when she will receive the new version.

Every process should have a tayloring advice to accompany it. So here it comes: You may not short cut the fixing, testing and communication part with the customer. You may use some short cuts in steps 6 through 9. But be prepared to return to the clean process when the shortcut turns out to be a cul de sac.

You may use your debugger instead of debugging output, but in the complex cases debugging output is easier and faster to use, especially if you have an automated test.

There are special cases that need some consideration, but those have to wait for a future post: Finding suitable starting points in step  6 and 7; Debugging in a distributed environment; Debugging with 3rd party software; reading stack traces.

What process do you use when debugging? What is missing? Let me know.

I like the concept, but it does not work for me. I read in a lot of different places and I read about 2-5 books or magazines in parallel most of the time. I do not want to carry those around all the time. In fact I read so many things in parallel because I don’t want to carry the books around. Instead I try to have a book at every place where I might want to read. One in the bed room, one in the bath, one in the living room, one at the office at LINEAS and one at the desk at the customer for the lunch breaks. And last night I had to buy a new one because I was traveling by train and hadn’t a book yet for that place.

No matter if you are more like jurgen or more like me, or if you are one of these weird people that read one book at a time: Use Tools for Reading. At least when you are reading in order to learn something, you should use the following tools:

1. a transparent ruler. Hold it under the current line. It will prevent you from loosing the line, and thereby enables faster reading. If a ruler is not available, a pen or a sheet of paper might work as well.
2. a pen. Put down notes. Put them on the margin of the book if you like or on post its, or on a seperate sheet of paper. Whatever, in my experience taking down notes, writing a short summary on after every chapter is the single most effective thing to prevent information to fall out of your ears, while you take it in through the eyes.

Reading is such an important thing, there really should be more discussion about how we do it. So what are your reading tips?

Andererseits hat die klassische Netzplantechink durchaus etwas für sich. Der Argumentation: Wenn A von B abhängt, kann ich erst mit A beginnen, wenn B abgeschlossen ist, leuchtet ein. Und so mancher Vertreter der Agilen Methoden verwechselt wohl agil mit chaotisch.

Leute die Worte wie Agil, Iterativ und Inkrementell nutzen, aber nicht erklären können machen die Sache auch nicht besser.

Ich habe jemanden gefunden, der nicht nur diese Unterscheidungen kennt, der weiß wie man in agil geführten Projekten plant und schätzt, sondern der darüber sogar Bücher geschrieben hat. Mike Cohen. Na gut, ich habe ihn nicht persönlich kennengelernt, aber ich habe zwei seiner Bücher gelesen: “Agile Estimating and Planning” und “User Stories Applied”.

Beide Bücher kann ich empfehlen, obwohl ich nicht empfehlen würde beide Bücher hintereinander zu lesen, wie ich es getan habe. Dafür ist die Schnittmenge des Inhalts zu groß.

Genug der Werbung: Wie plant nun das agile Projektmanagement? In letzter Instanz nicht so viel anders, als das klassische Projektmanagement, wenn es richtig gemacht wird. Es wird das geplant was planbar ist, und was für eine erfolgreiche Weiterarbeit notwendig ist. Bei der klassischen Netzplantechnik ist es naheliegend alle Aktivitäten gleich detailliert zu planen, obwohl dies weder realistisch noch förderlich ist.

Mike Cohen empfiehlt getrennte Planungen für unterschiedlichen Planungshorizonte: Projekt, Release, Iteration, Tag. Dadurch wird auch gleich ein weiterer typischer Fehler von klassischem Projektmanagement vermieden: Bei Projektbeginn wird der Projektplan erstellt und dann allenfalls mit dem Projektfortschritt aktualisiert. Klar, dass der bald nichts mehr mit der Realität zu tun hat. Aber wenn der detaillierte Plan nur bis zum Feierabend reicht, dann kommt man nicht drum rum am nächsten Morgen einen neuen Plan zu machen. Das gleiche gilt für die Pläne auf Iteration und Release Ebene.

Damit wird das Möglich, was für mich ein ganz wichtiger Aspekt der agile Projektarbeit ausmacht: Embracing Change (Änderungen umarmen?) d.h. Änderungen der Ziele und Vorgaben werden nicht als Störung des Projektes betrachtet, sondern als integraler, willkommener Bestandteil des Projektgeschäftes.

Aber was passiert mit den heiß geliebten Gantt-Charts und der Netzplantechnik? Diese sind tatsächlich hinfällig. Als Ersatz für die Abhängigkeiten im Netzplan werden die Anforderungen (Stichwort: User Stories) so gewählt, dass sie möglichst unabhängig voneinander sind. An dieser Stelle wird die Sache meiner Meinung nach wirklich spannend. Warum meint die Softwarebranche ohne diese Abhängigkeiten zurecht zu kommen, obwohl andere Branchen seit Jahrzehnten darauf schwören? Weil bei (gut geschriebener) Software jeder Teil geändert werden kann, ohne dass dies nennenswerte Auswirkungen auf andere Teile hat, während dies bei klassischen produzierenden Gewerbe unmöglich ist.

Man stelle sich mal vor, bei einem fertigen Gebäude soll das Fundament ausgetauscht werden … unmöglich, unbezahlbar. Bei einem Programm die Persistenzschicht austauschen? Kein wirkliches Problem, natürlich müssen beide Varianten der Persistenzschicht entwickelt und letztendlich bezahlt werden, aber bei dem Rest des Programm sollte sich recht wenig ändern. Während das klassische Gebäude wohl komplett ab und wieder neu gebaut werden müsste. Dadurch ist es möglich die Bestandteile in beinahe beliebiger Reihenfolge zu erstellen. Im Umkehrschluss bedeutet dies aber auch, Projektanteile die nicht so flexible disponiert werden können, müssen entsprechend langfristig geplant werden. Know How in diesem Bereich ist also nicht verloren.

In allen anderen Bereichen geht es meist um eine verschobene Gewichtung: Wenn Plan und Realität auseinander gehen, wird dies eher über Anpassung der Ziele, d.h. des Projektumfangs aufgefangen, als durch Veränderung des Arbeitsvolumens. Dabei trifft der Kunde die Entscheidung was genau gestrichen oder angepasst werden sollte, anstatt wie ich es oft erlebt habe Grabenkämpfe um die Übernahmen der Kosten zu führen.

Löst das alle Probleme? Ganz sicher nicht. Letzten Endes geht es in Projekten um Geld und da wird es Konflikte geben. Aber ich bin überzeugt, fast alle Projekte könnten von einer kleinen oder größeren Prise ‘Agile Estimating and Planning’ profitieren, nicht nur Softwareentwicklungsprojekte. Und wenn unsere Kunden das Buch lesen würden, könnten wir sie eher davon überzeugen gemeinsam ein Projekt zu machen anstatt gegeneinander.

Na gut, aber nur weil man nichts besonderes ist, kann man ja trotzdem mal reinschauen. Leider war kein Inhalt drin. Versteht mich nicht falsch: Seiten waren schon drin. Es standen auch Buchstaben und Bilder drauf, aber Inhalt war nicht dabei. Etwa ein Drittel der Seiten sind großformatige Werbung. Ganzseitig oder doppelseitig. Und wenn der Rest im Fernsehen liefe würde ständig ‘Dauerwerbesendung’ eingeblendet werden.

Keine Spur von Kreativität, bis auf das Geschäftsmodel. Wenn man nämlich nach dem Verlag googelt landet man bei einer Werbeagentur. Anstatt also wie üblich zu Inhalt passende Werbung zu suchen, oder für Werbung passenden Inhalt, haben die einfachWerbung mit Werbung kombiniert und verkaufen das ganze jetzt.

Falls euch die Zeitschrift interessiert … ich habe mein Exemplar schon weggeschmissen, aber das Oracle Magazin verfolgt ein ähnliches Konzept. Leider ist es kostenlos und durch die schlampige Redaktion schleichen sich eigentlich immer 3-4 Seiten Inhalt rein.

Man muss den DBAs und Datenbankentwicklern zu Gute halten, das selbst Martin Fowler refaktorn von Datenbanken für besonders schwierig hält und es daher dieses Thema in seinem Buch “Refactoring” mehr oder weniger vollständig ausgeschlossen hat. Dieses Thema haben mittlerweile andere bearbeitet und seit einigen Jahren ist eine gesondertes Buch zum Thema Refactoring von Datenbanken verfügbar. Ich halte dieses Buch für sehr wichtig und lesenswert und es sei allen, die mit Datenbanken zu tun haben dringenst an Herz gelegt.

Allerdings muss ich den potentiellen Leser warnen. Die Autoren Scott Ambler und Pramodkumar Sadalage haben keinen Trick auf Lager, wie sie Änderungen von Datenbanken zwischen den verschiedenen Instanzen synchronisieren. Bei Änderungen an Datenbanken müssen sehr oft auch Daten aktualisiert werden und dies geht nur mit dem Wissen um diese Daten, dies kann nicht automatisiert werden. Es wird hier also korrekter Weise auf die manuelle Pflege von Skripten verwiesen. Leider hat sich die Hoffnung der Autoren bisher nicht erfüllt, dass leistungsfähige Tools für die Unterstützung dieser Aufgaben entstehen. Es gibt zwar mittlerweile einige, die Skripte verwalten, feststellen welche noch eingespielt werden und diese einspielen oder zu einen SQL Script zusammenführen. Aber diese Tools fühlen sich an wie ein Faustkeil, wenn man Werkzeuge wie IDEA oder Eclipse gewohnt ist.

Sprachen

Das aktuelle Thema überhaupt ist sicherlich Sprachen. Durch die Allgegenwart von zwei wesentlichen Laufzeitumgebungen (JVM von Java/Sun und der CLR von .NET/Microsoft) ist es extrem einfach neue Sprachen mal auszuprobieren. Zu dem Thema empfehle ich den Artikel von Markus Völter.

Meine persönlichen Erkenntnisse dazu:

• Fast(?) nichts von den Konzepten ist neu. Die Basis für funktionale Sprache z.B. ist das Lambda Kalkül von 1930. Insbesondere das Polyglotte Programmieren ist doch längst Standard. Ich z.B. zähle in den meisten Projekten mindestens Java, SQL, PL/SQL, HTML und CSS zu meinem Handwerkszeug. Was sich ändern könnte, ist warum wir zwei oder mehr Sprachen einsetzen: Weil bestimmte Aspekte in der einen, andere in der zweiten Sprache besser darstellbar sind. Während bisher der Grund der Mangel an Alternativen ist. (Ja ich weiß, man kann auch in Oracle mit Java arbeiten. Aber wer das einwirft hat es noch nicht ernsthaft ausprobiert).
• Wir werden uns damit beschäftigen müssen. Heiße Kandidaten für die praktische Anwendung sind für mich: Groovy und Scala.
  Auch spannend finde ich Haskell. Ich habe vor vielen Jahren an der Uni Miranda gelernt und hätte nie gedacht, dass dies mal im Berufsleben relevant werden könnte.
  Als Physiker, der einmal intensiv mit Fortran gearbeitet hat finde ich auch Fortress sehr beeindruckend. Dies Sprache kann zumindest für Mathematiker und ähnliche sehr leserlich gerendert werden und ist speziell auf (massiv)parallele Ausführung ausgerichtet.

Womit wir bei einem weiteren Thema sind:

Concurrency

Das Moore’sche Gesetz als Basis des Quaketunings (18 Monate Quake spielen, schon ist die Anwendung doppelt so schnell) ist am Ende. Als ‘horizontale Ausweichbewegung’ werden uns von AMD und Intel Mehrkern CPUs auf den Schreibtisch gestellt. Dadurch geraten überall Leute in Panik, existierende Anwendungen würden nun wie die Fliegen von den Wänden fallen, da Threadingprobleme sich nun manifestieren.

Nun ja, ich weiß nicht was für Anwendungen ihr schreibt, aber ich schreibe beruflich entweder Swing oder Webanwendungen, die auf Datenbanken gehen. Nur ein sehr kleiner Teil der Arbeit steckt in komplexen Algorithmen, und ich habe noch nie etwas davon parallelisiert. Datenbanken und Webserver laufen ‘schon immer’ auf Mehrprozessormaschinen. Es sind heute halt 512 statt 16. Die Art und Weise wie dort Parallelverarbeitung eingesetzt wird, ist extrem einfach und daher handhabbar: Jede Anfrage bekommt einen Thread, und darf ihn für sich alleine verwenden, bis die Anfrage abgearbeitet ist. Zumindest sieht es aus der Sicht des Entwicklers so aus.

Nur in Swing muss man typischer Weise mit mehreren Threads arbeiten, da lang laufende Aktionen sonst die Darstellung der Anwendung blockieren. Dies wird man aber wenn irgend möglich minimieren, da jeder der Doug Leas Buch gelesen hat, weiß wie schwierig Concurrency ist.

Viele der neuen Sprachen haben aber Konstrukte, die die Verteilte Ausführung unterstützen und es ist ja nicht so, dass wir die nicht zu nutzen wüssten. Unabhängig von der Anzahl der Prozessoren gibt es nämlich einen Bereich, in dem Concurrency eine Rolle spielen sollte: bei dem Zugriff auf verteilte Ressourcen. Egal ob es die Datenbank oder der entfernte Web Service ist, wenn wir eine Anfrage abschicken und warten, bis die Antwort kommt, bevor wir die nächste Anfrage lostreten verschwenden wir mindestens Zeit, und meist auch wertvolle Ressourcen (mindestens den wartenden Thread). Je nachdem wie knapp die Ressourcen sind, wird man früher oder später genötigt sein, die Anfragen parallel anzustoßen und anschließend die Ergebnisse zusammenzuführen. Schön wenn die Sprache mit der man dies tut, ein solches Vorgehen angemessen unterstützt.

Security

Es gibt immer wieder Stimmen, die meinen, Security würde jetzt DAS große Thema. Vertraut mir, wird es nicht. Genauso wenig wie Gasmasken oder Panzertüren DAS große Thema werden. Aber Security ist ein Dauerbrenner, den niemand ignorieren sollte. Oder schließt ihr euer Auto und eure Wohnung nicht ab? Daher gab es auch auf der JAX Vorträge zu diesem Thema.

Für mich die wichtigsten Punkt waren dabei:

• * Der Deming Zyklus gilt auch hier. D.h.
  • Plant was eure Sicherheitsziele sind und was ihr dafür tun müsst. Wollt ihr euch gegen Skriptkiddies schützen? Oder haltet ihr die NSA für euren Feind? In letzterem Fall könnte aber auch ein Psychater helfen
  • Führt die Maßnahmen durch.
  • Prüft, ob die Maßnahmen wirksam sind.
  • Wenn die Prüfung negativ ausfällt, reagiert darauf.
• Schwierig an dem Security Thema ist, dass selbst gigantische Sicherheitsprobleme nicht von allen erkannt werden. Wenn ich in mein Haus eine Tür aus Pappe einbaue, brauche ich keinen Experten um zu erkennen, dass das eine schlechte Idee ist. Bei Software ist das ganze deutlich weniger offensichtlich. Ich habe die privaten Schlüssel für Zertifikate schon gemailt bekommen. Daher gibt es eine ganz wichtige Aufgabe, wenn eine Anwendung ‘sicher’ werden muss: Awareness schaffen. Alle Beteiligten (Entwickler, Designer, Tester, Administratoren, Anwender, …) müssen in Sachen Security geschult werden. Denn was nützt die schöne Sicherheitsarchitektur, wenn der Benutzer seines Sohnes Namen als Passwort verwendet und das auch noch per E-Mail verschickt und auf den Monitorrahmen schreibt?
• Security heißt nicht einfach Benutzer Authentifizierung und Authorisierung sondern durchdringt den gesamten Entwicklungsprozess.
  • Bei der Analyse müssen die Anforderungen aufgenommen werden.
  • Diese müssen bei der Architektur und dem Design berücksichtigt werden.
  • Es muss natürlich implementiert werden,
  • aber auch getestet,
  • deployed
  • und genutzt

  Und wie ich oben skizziert habe, gibt es auch in den Bereichen Herausforderungen, wo man sie normalerweise vielleicht nicht erwartet.

Architektur

Ist ein weiterer Dauerbrenner, und ähnlich wie bei Security lautet hier mein Hinweis Deming Circle! Eine Architektur hat eine Aufgabe zu erfüllen. Die Aufgabe sollte vorher klar sein und nachher muss geprüft werden, dass die Aufgabe gelöst wurde. Ansonsten ist Architektur ein Unfall oder Selbstbefriedigung des Architekten.

Durch das Thema Nr.1 ‘Sprachen’ gewinnen wir gerade im Bereich Architektur gerade gewaltig an Möglichkeiten:

• Unterschiedliche Sprachen für unterschiedliche Bereiche.
• DSLs für Spezialfälle
• AOP oder spezielle Sprachstrukturen für die Umsetzung von Architekturentscheidungen

SOA und BPM

Viel Hype und (fast) nichts dahinter.

Das 5. Element (Quintessenz)

Die Probleme bleiben die alten. Die Lösungen sind auch nicht neu. Die Zeiten bleiben interessant.

Entgegen der allgegenwärtigen Presens von Objekt Orientiertem Design in der Literatur und im Internet kommen in meiner Erfahrung diese Techniken oft nur im Infrastruktur Code zur Anwendung (GUI Frameworks, Web Frameworks, Datenbankzugriff …). Wenn es aber um das eigentliche Problem geht, ist die Basis auf einmal das Datenmodell. Ich weiß um den Wert einer guten Datenbank. Aber die Möglichkeiten Geschäftslogik in der Datenbank sichtbar zu machen sind extrem beschränkt. Es gibt nicht viel mehr als Foreign Keys, um Beziehungen zwischen Daten zu repräsentieren. Es ist also völlig ungeeignet das Domänen Modell, dass jeder Anwendung zu Grunde liegt wiederzuspiegeln. Wenn es aber nicht im Sourcecode ist, wo ist es dann? Gemäß Agilen Methoden: Nirgends, jedenfalls nicht in schriftlicher Form. Und gemäß Wasserfall oder V-Modell oder dergleichen? In einem veralteten Dokument!

Martin Fowler schlägt als anwendbares Enterprise Pattern das Domainmodel vor, das nach allen Regeln der objektorientierten Kunst erstellt wird. Evans liefert in seinem Buch nun das Handwerkszeug, um mit diesem Domänen Model möglichst produktiv zu arbeiten. Er beschreibt wie Refactoring, Patterns, Modularisierung und vieles mehr in diesem Kontext eingesetzt werden können um das Domänen Model im Source Code ausdrucksstark zu halten und wie es als Grundlage für eine gemeinsame Sprache (Ubiquitous Language) zur Basis sämtlicher Arbeit im Projekt wird. Dies alleine wäre schon Grund genug das Buch zur Pflicht für jeden Softwaredesigner und Architekten zu machen. Hinzu kommt, dass es sich sehr angenehm liest, unter anderem da er realitätsnahe Beispiele verwendet und Beispiele aus der eigenen Erfahrung bringt die zeigen was nicht funktioniert.

In manchen Reviews werden ihm Wiederholungen vorgeworfen. Einiges was so mancher für Wiederholungen hält, sind keine, sondern nur ähnliche oder verwandte Konzepte. Vieles schreibt aber tatsächlich mehrfach, allerdings in einem Umfang, den ich als sehr angenehm empfand.

Äußerst empfehlenswert.

Der Roman wird immer wieder gelobt und gepriesen dafür, dass er Projektmanagement Know How in Form eines Romans vermittelt.

Meine Manöverkritik fällt da etwas anders aus:

Als Roman ist das Buch katastrophal schlecht. Die Charaktere haben nicht ganz soviel Profil wie eine Briefmarke. Beim Spannungsbogen hat er die Sehne vergessen und das Happy End ist einfach nur angeklebt. Die innere Logik fehlt komplett: Warum hat ein kleines armes Land Unmengen an sehr guten Softwareentwicklern, die aber alle nichts zu tun haben und das seit dem Niedergang des Ostblocks, also seit ca. einem halben Jahrzehnt zum Zeitpunkt des Erscheinens des Buches Mitte der 90er? Warum wird ein Manager, der in der Lage ist ein Team von 15000 Entwicklern so zu leiten, dass unmögliche Termine eingehalten werden, gefeuert? Die Liste von Fragen ließe sich fortsetzen bis mein Herz streikt, also weiter zum nächsten Kritikpunkt.

Fachlich schreibt Herr De Marco des öfteren einfach nur Quatsch. Eine Functionpoint Analyse von 6 Projekten mit insgesamt 20000 (in Worten zwanzigtausend) Functionpoints innerhalb eines Tages gehört dazu. Oder die Qualitätsbewertung von einzelnen Mitarbeitern nach CMMI, was so sinnvoll ist, wie die Temperatur eines Vakuums messen zu wollen (Um fair zu sein CMMI wird nicht ausdrücklich erwähnt, aber es ist recht offensichtlich gemeint).

Die Lehren die der Hauptcharakter aus seinen Erlebnissen zieht sind in vielen Fällen doch äußerst zweifelhaft, so zum Beispiel die Hymnen auf Functionpoint Analyse und das Wasserfallmodell. Bei letzterem behauptet De Marco, die Ergebnisse würden um so besser, um länger und intensiver man sich mit dem Entwurf beschäftigt.

Zu allem Überfluss ist die Übersetzung hölzern und sagen wir mal eigenwillig. Wenn “Whiteboard” als Weißtafel übersetzt wird freut man sich nur noch, dass es wenigstens nicht Weißbrett geworden ist.

Am ärgerlichsten ist jedoch, dass das Buch die gemachten Versprechen nicht hält. Es geht die ganze Zeit um ein Experiment, in dem die Wirksamkeit von verschiedenen Managementmethoden mit einander verglichen werden sollen. Aber es werden fast nie Managementmethoden miteinander verglichen! Und wenn, wird die eine von einer völlig inkompetenten Person repräsentiert, so dass das Ergebnis weder überraschend noch lehrreich ausfällt.

Aber Tom De Marco hat nicht alles falsch gemacht. Jeder der sein Buch liest und glaubt, muss zu dem Schluss kommen, dass man bei einem Problem nur einen Berater ins Haus holen muss und schon flutscht es wieder. Da Tom De Marco selbst Berater ist, ist das Buch damit wohl eine der erfolgreichsten Werbebroschüre aller Zeiten.
Wieso habe ich das Buch also bis zum Ende gelesen? Das Buch liest sich extrem schnell. Da die Geschichte unintressant ist, und die Fakten äußerst dünn, kann man es innerhalb von ca. 4 Stunden ganz gut durchlesen.

Wen ich immer noch nicht von diesem Buch abbringen konnte, dem empfehle ich gleich noch eins: Der Minuten-Manager. Das Buch enthält weniger (falsche) Informationen, die Geschichte ist ähnlich schlecht wie von “Der Termin”, aber was entscheidend ist: Man kann es in ca 0,5 bis 1 Stunde durchlesen.

Um den Leser nicht völlig ohne Lesestoff zurückzulassen hier noch eine Buch, das mir schon vor geraumer Zeit wirklich gut gefallen hat: Cryptonomicon. Leider wird man auch hier wenig über Projektmanagement lernen, dafür gibt es aber viele interessante Stunden und nebenbei sogar noch ein wenig Wissen über Verschlüsselung und Geschichte.