Beiträge getagged mit computer
Buchkommentar – Adrenalin Junkies & Formular Zombies
Bei einem meiner Spaziergänge durch einen unserer Buchläden ist mir vor einiger Zeit das Buch “Adrenalin Junkies & Formular Zombies – Typisches Verhalten in Projekten” von Tom DeMarco und anderen (konkret: die “Atlantic Systems Guild”) aufgefallen. Nachdem ich die anderen Bücher von Tom DeMarco zu Softwareengineering und Projektarbeit (konkret: The Deadline/Der Termin, Peopleware oder Slack/Spielräume) mit großen Vergnügen verschlungen habe, landete auch die Neuentdeckung auf meinem Still-to-Read-Stapel …
Mein erster Eindruck nach dem Lesen: zuerst einmal etwas enttäuscht … Das Buch liefert zwar viele interessante Einblicke in (Software-)Projektarbeit und damit auch gute Anregungen, wo man hinschauen oder eingreifen sollte/könnte – aber es fehlt die zusammenhängende, geschichtenartige “Schreibe”, die ich bisher bei Tom DeMarco gewohnt war – und geliebt habe.
Denn das Buch ist kein zusammenhängender Text, sondern eine Sammlung von 86 Mustern, die bei (Software-)Projektarbeit beobachtet werden können. Jedes Muster ist auf einer bis vier Seiten kurz beschrieben. Dabei ist die Qualität (und Lesbarkeit) der Beschreibungen stark unterschiedlich. Weiterhin sind positive, negative und neutrale Muster wild gemischt.
Hier noch die “Muster”, die mir beim Lesen des Buches als besonders lesenswert bzw. erwähnenswert aufgefallen sind – mit ein paar Kommentaren von mir dazu.
7) Manana: “Wir alle verfügen über Zeitfenster, innerhalb derer wir erkennen, dass wir in Gang kommen und dranbleiben müssen, um eine Tätigkeit abzuschließen. Stichtage jenseits dieser Zeitfenster erzeugen kein Gefühl von Dringlichkeit und folglich auch nur eine geringe Motivation, sofort zu handeln.” (S. 19) – “Ausserhalb dieses Wahrnehmungsfensters befindet sich Manana. Manana bedeutet, dass wir zwar grundsätzlich einsehen, dass wir diese Arbeit erledigen müssen, aber nicht begreifen, dass wir umgehend damit beginnen müssen, um rechtzeitig fertig zu sein.” (S. 20).
Die Lösung ist (wie bei vielen der Muster/Probleme) einfach: Zwischenziele definieren, die innerhalb des Zeitfensters liegen. Trotz dieser einfachen Lösungsmöglichkeit wird aber nicht immer (rechtzeitig) erkannt, dass überhaupt ein Problem existiert.
26) Der Versuchsballon: “Bei einem Versuchsballon handelt es sich (…) um einen Lösungsvorschlag, von dem Sie allerdings wissen, dass er unvollkommen und/oder fehlerhaft ist, und den Sie bewusst einsetzen, um von Kollegen oder Kunden Kritik zu bekommen.” (S. 68).
Schöner habe ich die Idee der iterativen Entwicklung, des häufigen Generierens und Diskutierens von Prototypen noch nicht dargestellt gesehen. Dazu passt auch das auf S. 69 abgedruckte Zitat von Albert Schweitzer sehr gut: “Beispiele sind nicht das Hauptmittel um andere zu überzeugen. Sie sind das einzig mögliche Mittel.”.
75) Die Kühlschranktür: “Teammitglieder hängen ihre Arbeitsergebnisse routinemäßig für alle sichtbar aus.” (S. 185).
Hier wird besprochen, was mit Awareness / einem Gewahrsein über die Arbeit der anderen / den Stand der Arbeiten bzw. des Projektes erreicht werden kann. Das passt auch sehr gut zu den in vielen anderen Mustern angesprochenen Problem mit der zu starken (blinden) Konzentration auf in Vorgehensmodellen vorgeschriebenen Dokumenten zur Fortschrittsdokumentation (z.B. Muster 79 Papierfabrik).
Anstelle einer “Kühlschranktür” kann man natürlich auch Medien wie Blogs benutzen – sollte sich aber immer der Vorteile der Kühlschranktür bewusst sein bzw. versuchen sie nachzubilden!
Gut hierzu passt auch das Muster 81 Lagezentrum. Hier wird ein Projektraum empfohlen, der erstens Informationsaustausch und Informationsbewahrung sicherstellt – und dem Projekt einen sichtbaren Wert gibt.
76) Morgen scheint die Sonne wieder …: “Der Projektmanager ist davon überzeugt, dass der durchschnittliche künftige Fortschritt den durchschnittlichen zurückliegenden Fortschritt übertrifft.” (S. 187).
77) Einer geht noch: “Die Beteiligten sichern Unterstützung für ein Projekt zu, blähen es dann aber immer weiter auf, bis das Projekt unter der Eigenlast zusammenbricht.” (S. 190).
83) Aus gehabtem Schaden nichts gelernt …: “Ein Team erkennt seine Fehler, aber wiederholt sie trotzdem.” (S. 203).
In diesem Muster wird ausführlich auf den Aspekt der Lessons-learned eingegangen und auch einige konkrete Tipps zu deren erfolgreichen Durchführung/Implementierung gegeben (S. 205). Erstmal sollten Nachbesprechungen überhaupt abgehalten werden. Dann sollte vermieden werden, dass die Besprechungen nur zum “Dampfablassen” genutzt werden – z.B. nur Beschreibungen von Problemen gesammelt werden, aber keine Handlungsanweisungen zur zukünftigen Begebung.
Buchkommentar – Hackers & Painters
Vor einige Zeit bin ich mal auf “Hackers & Painters – Big Ideas from the Computing Age” von Paul Graham aufmerksam geworden – ich glaube es war wegen des Vergleichs von Computer-Hackern mit Malern – beides “Macher” :-) Als “Möchte-Gern-Hacker/Macher” musste ich mir das Buch natürlich sofort besorgen – und inzwischen ist auch auch nach oben auf meinem Still-to-Read-Stapel vorgerückt und gelesen worden … Hier ein paar Kommentare dazu.
In Kapitel 2 geht der Autor auf Charakteristika von “Hackern” ein – und darauf, dass “Hacking” als schöpferische Tätigkeit viel mit Malen und Schreiben zu tun hat. Hier ein paar Zitate:
- “what hackers and painters have in ommon is that they’re both makers”
- “computer science is a grab bag of tenuously related areas thrown together by an accident of history”
- “Programs should be written for people to read, and only incidentally for machines to execute” (Structure and Interpretation of Computer Programs, Harold Abelson und Gerald Sussman, MIT Press, 1985)
Kapitel 4 ist den Vorteilen von “Web/Server-basierter Software” gegenüber “Client-basierter Software” gewidmet. Sowohl aus Sicht der Benutzer als auch aus Sicht der Firmen, die Software zur Verfügung stellen. Graham schildert am Beispiel seiner Firma Viaweb vor allem den Vorteil des direkten Kontaktes zu den Benutzern als auch der Möglichkeit schnell reagieren und in kurzen Abständen neue Versionen der Software veröffentlichen zu können. Das erinnert doch sehr an die Argumentation rund um Web 2.0 …
In Kapitel 6 geht Graham auf Vermögen/Reichtum (engl. “wealth”) ein. Er hat dazu einiges zu sagen – vor allem:
- Vermögen wird nicht einfach verteilt, sondern geschaffen – wenn also jemand ein Stück Software schreibt, das die Bedürfnisse von Kunden befriedigt (d.h. für das eine Nachfrage existiert), dann wird damit Vermögen geschaffen
In Bezug auf Firmen und Vermögen/Reichtum sagt er deshalb auch: “What most businesses really do is make wealth. They do something people want.”
Interessant sind in diesem Zusammenhang auch seine Ausführungen zur Bezahlung für geleistete Arbeit. Hier sei das Problem, dass in großen Unternehmen nicht festgestellt werden kann, was einzelne Mitarbeiter zum Wertzuwachs beitragen bzw. in wie weit sie für einen Wertzuwachs verantwortlich sind. Dies sei nur in Ausnahmefällen möglich (messbar) – bei Vertriebsmitarbeitern und beim Unternehmensvorstand – oder bei kleinen Unternehmen (Startups). Wenn eine Möglichkeit der “Messung” existiert, dann sieht Graham keine Probleme darin, dass die Gehälter um den Faktor 100 abweichen (vom Unternehmensdurchschnitt). Er führt dazu an, dass auch im alten Rom die Preise für Sklaven je nach Fähigkeiten um den Faktor 50 abgewichen sind (S. 111).
Kapitel 10 – 14 behandelt das Thema Programmiersprachen – mit dem Resumee, dass Java ein toter Pfad der Evolution von Programmiersprachen ist (ein “Neandertaler”), und dass Lisp die mächtigste Programmiersprache ist und sein wird (mit ihren Nachkommen wie z.B. Ruby). Siehe hierzu meine ausführlichen Ausführungen in einem früheren Post.
Kapitel 15 widmet sich schließlich noch dem Thema “Design vs. Research”. Graham zeigt das an dem Beispiel auf, dass er einen neuen Lisp-Dialekt “designed” – nicht aber “research” in Programmiersprachen betreibt. Der Unterschied ist seiner Meinung nach darin, dass man sich beim Design mehr auf den Benutzer konzentriert. Design beginnt mit der Frage, für wen man entwirft und was die Nutzer davon haben. Ein guter Architekt beginnt damit zu klären, was die Benutzer brauchen (nicht was sie wollen!).