Beiträge getagged mit software
Die Vasa und Software Engineering
Vielleicht ist dem einen oder anderen die Geschichte von der Vasa bekannt, ein Schiff, das im 17Jhd in Schweden (Stockholm) gebaut worden ist. Ich selbst habe das Schiff und seine Geschichte auf der ECSCW-Konferenz in Stockholm 1995 kennen gelernt.
In der neuesten Ausgabe der Communications of the ACM (Vol 51, No 9, S 25ff) berichtet George Neville-Neil die Geschichte der Vasa im Kontext der Lehren, die daraus für Software Engineering gezogen werden können. Und diesen Bericht möchte ich hier wiedergeben:
The Vasa was built between 1626 and 1628 for King Gustavus Adolphus of Sweden, who was, at that time, attempting to rule the Baltic Sea. In the 17th century, rulers were expected to be capable of more than just giving orders, so Adolphus not only organized wars, he also helped design the ships of his naval fleet. At the time Swedish warships had one deck of cannons on each side from which they fired fusillades at enemy ships, sometimes even hitting the other ships and damaging them. When the Vasa was commissioned, this single row of cannons was considered state of the art.
Some time during the construction of the ship Adolphus found out that the Poles had ships with two decks of guns, so he modified the design of the Vasa to have a second gun deck. This would have made it the most powerful naval vessel of the time, capable of delivering a broadside of devasting proportions. The men he had contracted to build his ships attempted to explain that the ship had too little ballast to support two gun decks, and that the resulting ship likely would be unsafe to sail. The King insisted – just like, say, many project managers – that his orders should be followed. On a software project you can quit, but if the King is your boss you might lose more than your job – you might, say, lose your head – so the project went forward.
In 1628 the ship was finally ready for quality assurance (QA) testing. Seventeenth-century QA of ships was a bit different from what might happen today. Thirty sailors were picked and asked to run back and forth, port to starboard, across the deck of the ship. If the ship didn’t tip over and sink, then the ship passed the test. (…) After only three runs across the deck the Vasa began to tilt wildly and the test was canceled. The test may have been canceled, but not the project. This was the King’s ship, after all, and she would sail. And sail she did.
On August 10, 1628, in a light breeze, the Vasa set sail. She was less then a mile from dock when a stiff breeze knocked her sideways. She took on water, and sank in full view of a crowd of thousands od onlookers. (…)
Es hat sich wirklich nicht viel geändert im Projektmanagement …
Software für MacOSX
Nachdem ich als “intensiver” Mac-User hin und wieder gefragt werde, was ich denn so als Software nutze / empfehlen kann, will ich das mal zum Anlass nehmen, die Antwort auf die Frage in einem Blog-Post zu verewigen – vielleicht interessiert es ja noch jemanden – und auch falls nicht, dann kann ich zumindest in Zukunft immer auf den Post verweisen ;-)
Hier also eine Liste der Anwendungen / Tools, die ich wirklich häufig nutze – und weiter unten noch ein paar, die ich nicht so häufig nutze, aber ganz interessant finde.
- Safari – der Standard Web-Browser von MacOSX – Ich habe zwar auch Firefox installiert, habe aber aktuell nur eine Web-Anwendung, die nicht mit Safari funktioniert (die Mailbox-Forwarder-Konfiguration bei Strato) und für alles andere finde ich Safari die besser integrierte Lösung
- Mail – der Standard Mail-Reader von MacOSX – Inzwischen verwende ich Mail auch für das Verwalten von RSS Feeds – und das einzige was mich daran stört ist, dass ich noch keine Möglichkeit gefunden habe einfach auf die Feed-URLs zuzugreifen nachdem ein Feed angelegt ist. Ich habe auch schon mal mit Erweiterungen zu Mail experimentiert, konkret MailTags – aber die Suchemöglichkeiten von Mail sind so gut, dass ich damit bisher immer zurecht gekommen bin.
- Addressbook – Auch zur Adressverwaltung greife ich auf den Standard zurück – Es ist einfach schön, wenn man dort Bilder zu den Personen einstellt und diese dann sofort in Mail sehen kann – Integration is King – das einzige was mich bisher gestört hat ist die schwache Etikettendruckfähigkeit
- iCal – Ich habe zwar schon mal Thunderbird etc genutzt – aber das kann einfach nicht mit der Integration auf der Plattform mithalten – deshalb auch hier “den Standard”
- iTunes – simply the best … und zur Synchronisation mit meinem iPhone auch unbedingt notwendig
- iPhoto – ich habe lange rumexperimentiert – und schließlich dann doch meine ganzen digitalen Bilder in iPhoto importiert
- TimeMachine – vor OS 10.5 habe ich SilverKeeper benutzt um regelmäßig Backups zu machen – inzwischen bin ich auf TimeMachine umgestiegen – und hatte auch schon erste Recovery-Erfolge ;-)
- MS Powerpoint – Ich will mir zwar schon länger mal Keynote anschauen – denke aber, dass bei den vielen Präsentationen, die ich weiter zusammen mit Windows-Nutzern machen werde, Powerpoint nicht ganz zu verdrängen ist.
- MS Word
- MS Excel
- Skype
- Thunderbird – Für E-Mail verwende ich ja Mail, aber zum gelegentlichen Lesen von Usenet News ist mir Thunderbird am liebsten
- Mars Edit – Ein Offline-Blog-Editor – nutze ich um Beiträge für meine verschiedenen Blogs zu schreiben
- MacGiro – nutze ich zur HBCI-Kontoverwaltung
- Mori – “Your notes, organized” – Eine sehr schöne Anwendung um Notizen zu machen und zu verwalten – quasi ein elektronischer Zettelkasten – verwende ich für mein persönliches offline-Wissensmanagement
- Sophos AntiVirus – Ich weiss zwar nicht ob das nötig ist, aber Sophos ist Standard bei uns an der Uni.
- Spanning Sync – Synchronisation zwischen dem lokalen iCal und Google Calender – brauche ich, da ich über Google Calender meinen Terminkalender mit meinen Mitarbeitern teile
- TV-Browser – Wenn ich mal “geplant” fernsehen will – neuerdings sind zwar nicht mehr die Programme aller Sender verfügar – reicht aber immer noch
- CocaMySQL – Ein sehr schöner Client für MySQL (das ich natürlich auch lokal installiert habe)
- Mindmanager – Der Standard zum Mindmapping – inwischen auch auf dem Mac verfügbar
- Growl – Ein flexibles lokales Notifikationssysteme – nutze ich um auf Statusänderungen meiner Skype-Kontate oder neue E-Mails hingewiesen zu werden
- Adobe Acrobat – Den frei verfügbaren Reader braucht man eigentlich nicht – da ist das bei MacOS beiliegende Preview völlig ausreichend – Nur wenn man PDF-Dateien auch editieren will, dann führt aktuell noch kein Weg an Adobe Acrobat Professional vorbei
- VLC – Bei MacOS liegt zwar Quicktime bei, für manche Videoformate ist VLC aber wohl die bessere/einzige Lösung
- emacs, svn, java/ruby/… – Irgendwie habe ich mich mit den “neuen” integrierten Entwicklungsumgebungen noch nicht angefreundet – Emacs ist mir integriert genug ;-)
Weiteres:
- Parallels – Tolle Lösung um gelegentlich mal Windows-Anwendungen laufen zu lassen – viele sind das bei mir eh nicht – gelegentlich mal den Internet Explorer um Webseiten zu testen – und gelegentlich mal MS Access um es in der Vorlesung vorzuführen – das wars dann auch schon …
- Gimp – Wer braucht schon Photoshop … Gimp ist kostenlos und kann genau so viel
- MacTheRipper – Eine kostenlose Anwendung um DVDs auf die Festplatte zu kopieren
- Endnote – habe ich mal benutzt – aber inzwischen verwalte ich alle meine Literaturreferenzen online auf bibsonomy – Das Web 2.0 / Social Software lässt grüßen … (Btw: 100% zufrieden bin ich mit bibsonomy noch nicht – aber die Alternative citeUlike hat mir auch nicht besser gefallen – und bibsonomy hat eine vernünftige API – d.h. theoretisch könnte man alles machen was man will ….)
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!).