RoR-Marketing-Videos
Per Zufall bin ich heute auf ein Youtube-Video gestoßen, in dem eine Ruby on Rails-Firma die Mac-Werbevideos als Vorlage genommen hat und RoR u.a. auch mit Java vergleicht. Logischerweise ist der RoR-Guy natürlich der coole Typ und der Java-Guy entspricht dem PC-Langweiler der Apple-Videos.
Das Video spricht natürlich in erster Linie Ruby-Leute an, aber auch als Java-Entwickler fand ich das Video recht amüsant. Ein wenig Selbstironie schadet nie. Und es spricht - wenn auch sehr plakativ - das allen Java-Entwicklern wohlbekannte Problem des Deployments an.
In einer ganze Folge von Videos bekommt natürlich nicht nur Java sein Fett ab, sondern auch ColdFusion, PHP oder .NET. Auf der Commercials-Seite sind alle Videos aufgelistet. Zumeist ist der Apple-Stil recht gut kopiert, allerdings kommt bspw. das PHP-Video doch ein wenig belehrend und zu konkret daher und dem RoR-Guy fehlt dann doch das Charisma des Apple-Guys. Vergleichbar ist sicherlich der Gehalt zwischen den RoR-Videos und den Apple-Videos. Aber was erwartet man schon von Marketing-Videos ;-)
Das Thema dynamische Sprachen werde ich hier im Blog sicher noch ab und an mit ernsthaften Beiträgen aufgreifen, aber für heute muss der Hinweis auf die Videos genügen.
Gepostet am 02.03.2008 um 08:38 | Kommentare[0]
Warum "No Silver Bullet"?
Der Titel dieses Blogs ist eine Hommage an Fredericks P. Brooks. Bereits 1975 hat Brooks das Standardwerk "The Mythical Man-Month" geschrieben. Zwanzig Jahre später erschien eine Jubiläumsausgabe, die zusätzlich zum unveränderten Originaltext noch diverse Aufsätze Brooks' enthält. Einer davon ist der bereits 1987 in der Zeitschrift "Computer" der IEEE veröffentlichte Text "No Silver Bullet – Essence and Accident in Software Engineering". Trotz des für IT-Verhältnisse fortgeschrittenen Alters haben weder Brooks Buch noch der Aufsatz "No Silver Bullet" an Aktualität verloren. Ich kann nur jedem in der Software-Entwicklung Tätigen dieses Buch wärmstens empfehlen.
The Mythical Man-Month
Eine der Kernthesen Brooks im Buch "The Mythical Man-Month" ist, dass es ein fataler Fehler ist, Projekte, die bereits in Zeitverzug gekommen sind, durch zusätzliche Programmierer retten zu wollen:
"Adding manpower to a late software project makes it later."
Diese zentrale Aussage seines Buches bezeichnet Brooks selber als "Brooks's Law". Brooks argumentiert, dass das Einarbeiten neuer Projektbeteiligter, die Änderung der Aufgabenteilung und der erhöhte Kommunikationsbedarf durch mehr Projektbeteiligte jeden möglichen Nutzen der zusätzlichen Kräfte mehr als aufzehren. Brooks warnt allerdings nicht nur davor, dass ein unrealistischer Zeitplan durch mehr Kräfte kaum zu korrigieren ist, sondern kritisiert die Messgröße "Personenjahre" insgesamt und bezweifelt deren Aussagekraft:
"Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable."
Aber Menschen und Zeit sind nicht ohne Konsequenzen austauschbar. Der im Verhältnis zu den eingesetzten Kräften mehr als linear steigenden Kommunikationsaufwand, die individuellen Fähigkeiten der unterschiedlichen Kräfte, verlorenes Wissen durch abgezogene oder abgewanderte Mitarbeiter, der Einarbeitungsaufwand neuer Mitarbeiter und die nur bedingt gegebene Teilbarkeit der Aufgaben führen dazu, dass die Größe Personen-Monat als entscheidende Bezugsgröße im Planungsprozess ungeeignet ist.
Auf die weiteren Thesen des Buches gehe ich hier nicht ein. Der interessierte Leser kann diese aber zusammengefasst auf der englischen Wikipedia-Seite zum Buch nachlesen.
No Silver Bullet
In seinem Aufsatz "No Silver Bullet - Essence and Accident in Software Engineering" räumt Brooks mit der Hoffnung auf den großen Durchbruch in der Software-Entwicklung auf. Brooks teilt dazu die Schwierigkeiten bei der Softwareerstellung in zwei Klassen: In Schwierigkeiten, die der Natur der Software selbst innewohnen (essential difficulties) und denen, die mit der Art, das Problem zu lösen, zu tun haben (accidental difficulties). Die akzidentellen Schwierigkeiten umfassen beispielsweise Probleme, die mit der verwendeten Programmiersprache, der Methodik und dem Prozess zu tun haben.
Akzidentelle Schwierigkeiten konnten in der Vergangenheit durch Hochsprachen, geeigneten Werkzeugeeinsatz oder auch Modularisierung verringert werden, und auch zukünftig sind hier Verbesserungen zu erwarten. In der Java-Welt kann man als ein Beispiel für akzidentelle Schwierigkeiten die Entwicklung mit EJBs in den Versionen 1.x und 2.x anführen. Durch die EJB-Spezifikation 3.0 wurde die Entwicklung mit EJBs deutlich erleichtert und weitere Verbesserungen sind für die nächste Version geplant.
Das eigentliche Problem in der Software-Entwicklung stellen aber nicht die akzidentellen Schwierigkeiten dar, sondern die Probleme, die Software an sich innewohnen.
Hier benennt Brooks vier Probleme:
- Komplexität
- Konformität
- Veränderlichkeit
- Unsichtbarkeit
Die Komplexität von Softwaresystemen wächst mit der Anzahl der Aufgaben und der zu verwaltenden Elemente stärker als linear an. Dieses Wachstum ergibt sich schon allein aus der Aufgabenstellung und der mit der steigenden Anzahl der Elemente zahlreicher werdenden Abhängigkeiten und Verflechtungen.
Die Probleme der Softwareentwicklung verschärfen sich durch die geforderte Konformität. Konformität bedeutet, dass Software eine Vielfalt von Anforderungen abdecken muss, mit diesen konform gehen muss. Dies können Gesetzesvorgaben sein, aber auch Anforderungen der Nutzer an das System, die sich wiederum nicht mit den Anforderungen des Managements an das System decken müssen.
Da Software jederzeit aus den Sourcen neu generiert werden kann, unterliegt sie einer hohen Veränderlichkeit. Auftraggeber fordern bei Software Änderungen leichter ein als bspw. bei physikalisch vorliegenden Produkten wie Autos, Häusern oder Computern. Solche Produkte werden zumeist erst mit einer neuen Generation Änderungen enthalten. Bei Software hingegen werden Änderungen unmittelbar eingefordert und Nutzer kommen gerade durch den Einsatz des Produkts häufig erst auf Ideen für Verbesserungen. Schlussendlich geht der Lebenszyklus von Softwaresystemen über den Lebenszyklus der Ursprungshardware hinaus. Zumindest Systemsoftware (Betriebssysteme, Datenbanken etc.) muss darauf reagieren und angepast werden.
Die vierte Eigenschaft, die Software inhärent ist, ist ihre Unsichtbarkeit. Softwaresysteme lassen sich nur bedingt visualisieren und wenn, dann auf keinen Fall mit nur einem einzigen Diagramm oder 3D-Modell. Graphische Repräsentationen, physikalische oder virtuelle Modelle helfen sowohl Auftraggeber als auch Auftragnehmer, ein gemeinsames Verständnis vom Produkt zu bekommen. Dies ist beispielsweise in der Architektur oder dem Autobau möglich, in der Softwareentwicklung jedoch nur bedingt.
Diese vier Probleme lassen sich laut Brooks nicht - zumindest nicht entscheidend - verringern. Demnach kann man die Softwareentwicklung nur bedingt optimieren. Bahnbrechende Erfolge werden sich so voraussichtlich nicht ergeben.
Brooks zeichnet dennoch keineswegs ein düsteres Bild. Er bezeichnet sich selbst als Optimisten und glaubt fest an weitere, wenn auch langsame, schrittweise Verbesserungen. So setzt er seine Hoffnung auf eine verstärkte Modularisierung und Kapselung und auf visuelle Repräsentationen (der Plural ist hier entscheidend) des zu erstellenden Systems. Darüber hinaus bietet sich häufig auch, so Brooks, Kaufsoftware an. Gekaufte Software ist heutzutage freilich in aller Regel durch Freie Software zu ersetzen. Die größte Hoffnung liegt Brooks zufolge allerdings in der Auswahl geeigneter Entwickler und Designer - eine Hoffnung, die er mit anderen Experten teilt.
Es ist erstaunlich, wie modern sich Brooks nach mehr als zwanzig Jahren noch liest. So kann man sein Plädoyer für stärkere Kundeneinbindung, iterative Zyklen und für Rapid Prototyping als Aufruf zu einer agilen Methodik lesen. Auch warnt er davor, eine Sprache zu überfrachten (eine Diskussion, die in der Java-Welt derzeit im Gange ist), weist aber auch darauf hin, dass man der Wahl der Sprache nicht zu viel Bedeutung zumessen sollte.
Kritiker von Brooks
Die im Buch "The Mythical Man-Month" vertretenen Thesen sind bis heute weitgehend unwidersprochen. Der Aufsatz "No Silver Bullet" hingegen wurde mehrfach kritisiert. Zwei interessante kritische Beiträge sind David Havels Artikel "Biting the Silver Bullet. Toward a Brighter Future for System Development" (erschienen in der IEEE-Zeitschrift "Computer" vom Januar 1992 und auf deren Website gegen Bezahlung erhältlich) und Brad J. Cox Beitrag "There Is a Silver Bullet" im Dr. Jobbs Journal vom Dezember 2004. Beide Kritiker bringen viele wichtige Ergänzungen, können aber Brooks These nicht überzeugend widerlegen. Brooks selber geht in einem Kapitel der zweiten Auflage seines Buches "The Mythical Man-Month" auf beide (und weitere) Kritiker ein. Ein weiterer Grund, sich das Buch vorzunehmen ;-)
Konsequenzen? Leider Fehlanzeige!
Obwohl die erste Auflage des Buches bereits 1975 erschienen ist, 1995 eine Jubiläumsausgabe folgte und 2003 auch eine deutsche Ausgabe herausgekommen ist (2004 sogar als Hörbuch), hat man in der täglichen Arbeit das Gefühl, dass es diese Texte nie gegeben hätte.
Was sehen wir im Projektalltag beispielsweise immer wieder? Genau den von Brooks kritisierten Versuch, das Projekt durch zusätzliche Leute zu retten. Und dies häufig auch noch zu einem sehr späten Zeitraum im Projekt, wenn sich das höchstwahrscheinliche Reißen der Deadline nicht mehr verheimlichen lässt. Management und Projektleitung sind sich erschreckend einig darin, die Warnungen Brooks' zu ignorieren, und verwenden Personenjahre immer noch als zentrale Planungsgröße.
Derweil wird regelmäßig eine neue Technologie oder Methode als der Stein der Weisen gefeiert. Mal ist es Strukturierte Programmierung, später Objektorientierung, ein anderes mal Komponentenorientierung oder in jüngerer Zeit SOA, inzwischen ergänzt um den Enterprise Service Bus. Hauptnutznießer sind nicht die Abnehmer und Nutzer der Software, auch nicht die Firmen, die hoffen, mithilfe dieser Technologien schneller bessere Software entwickeln zu können, als vielmehr die Hersteller der zum aktuellen Hype passenden Tools und die Consultants, die die neue Technologien predigen und in die Entwicklungsmannschaften tragen sollen.
Zugegeben, viele dieser Methoden und Techniken haben gegenüber der vorherigen Art, Software zu entwickeln, tatsächlich Verbesserungen gebracht. Allerdings waren dies stets nur graduelle Verbesserungen und keineswegs die vielfach gepriesenen Durchbrüche. Und wenn Brooks Recht hat, dürfte das Mildern der akzidentellen Probleme für den Gesamtaufwand immer weniger Bedeutung haben. Schließlich ist der Kern des Problems, sind die essentiellen Probleme bis heute nicht gelöst. Und es ist offen, ob eine Lösung überhaupt möglich ist. Die immer wieder marktschreierisch angepriesenen Tools, Prozesse und Hypes sind es jedenfalls nicht. Turski fasst es passend zusammen (zitiert nach Brooks):
"Of all misguided scientific endeavours, none are more pathetic than the search for the philosopher's stone, a substance supposed to change base metals into gold. (...) The whish to see a way out, against all odds, even when it is proven that it does not exist, is very, very strong. And most of us have a lot of sympathy for these courageous souls who try to achieve the impossible. And so it continues. Dissertations on quaring a circle are being written. Lotions to restore lost hair are concocted and sell well. Methods to improve software productivity are hatched and sell very well."
In dem Sinne: Happy Coding!
Gepostet am 14.02.2008 um 09:28 | Kommentare[1]
