Geschwindigkeit vs. Beherrschbarkeit

Die Standish-Group rechnet uns in ihrem CHAOS-Report regelmäßig vor, wie schlecht es um die Softwareentwicklung als Industriezweig steht: Termine werden nur selten eingehalten, Budgets maßlos überschritten und die gelieferte Funktionalität ist unpassend.
Allen ist seit Jahrzehnten klar: "Wir müssen was tun". Ebenfalls schon lange ist klar: "Wir müssen schneller werden!" So rufen es Entwickler und IT-Manager ins Marktgetümmel und die kommerziellen und nicht-kommerziellen Hersteller antworten: "MDA, MDSD, Spring, Hibernate, JSF, SOA, etc.". Die einschlägigen IT-Konferenzen sind voll mit diesen Themen. Diese Technologien werden uns retten. Oder doch nicht? Was haben uns denn die Technologien gebracht, die vor wenigen Jahren als Heilsbringer verkauft wurden (CASE, Software-Factories, Java, etc.)? Ich will nicht behaupten, dass diese Technologien oder ihre aktuellen Hype-Nachfolger keine positiven Effekte hatten. Bezogen auf die Kriterien der Standish-Group lässt sich aber kein nennenswerter Fortschritt ausmachen.
Wenn man genauer hinsieht, bemängelt der CHAOS-Report auch gar nicht, dass wir zu langsam arbeiten. Kritisiert wird, dass wir unsere Projekte nicht beherrschen. Softwareprojekte wissen häufig bereits kurze Zeit nach dem Kick-Off nicht mehr, wo sie stehen. Davon, eine vernünftige Prognose für die Zukunft zu haben, können diese Projekte nur träumen.
Naja, aber immerhin dürften die neuen Technologien auch nicht schaden. Nein? Doch! Die Einführung einer neuen Technologie oder Vorgehensweise bringt immer Instabilität. Eine neue Technologie in ein instabiles Projekt einzuführen, macht das Projekt also nicht stabiler, sondern instabiler.
Folglich sollten neue Technologien immer nur auf der Basis eines stabilen Projektes eingeführt werden. Die Einführung muss dann aktiv begleitet werden, um nach der unausweichlichen Instabilität schnell wieder in stabiles Fahrwasser zu kommen.
Langer Rede kurzer Sinn: Beherrschbarkeit kommt vor Geschwindigkeit.

Post bewerten

Hibernate 3 auf der W-JAX

Ich habe auf der W-JAX am 14.11.05 zusammen mit Arno Haase und Robert Beeger einen Power-Workshop zu Hibernate 3 gegeben. Ca. 70 Teilnehmer ließen sich für Hibernate-Grundkonzepte erläutern und vollzogen die Beispielprogramme an ihren Notebooks nach.
Interessanterweise hatte ca. ein Drittel der Teilnehmer bereits Projekterfahrungen mit Hibernate. Ich war etwas überrascht über diesen hohen Anteil, weil die Ankündigung des Power-Workshops explizit Hibernate-Einsteiger als Zielgruppe definierte.
Gerade diese Mischung hat dann aber doch einige interessante Impulse gegeben. Die Teilnehmer mit Hibernate-Erfahrung konnten interessante eigene Erfahrungswerte beisteuern.
Die beim Workshop behandelten Themen umfassten:

• OR-Mapping mit XML-Mapping-Dateien
  
• Queries mit HQL und Criteria-API
  
• Lifecycle persistenter Objekte
  
• Sessions, Transaktionen und Caching
  
• Best Practices für Web-Anwendungen mit Hibernate
  
• Best Practices für Client-Server-Anwendungen mit Hibernate
  
• Zusammengesetzte Primärschlüssel
  

Die Folien zum Power-Workshop sowie den Beispielcode kann man bei it-agile herunterladen.

Post bewerten

Neues Buch über testgetriebene Entwicklung

Jetzt ist es endlich da, das Buch über testgetriebene Entwicklung von Frank Westphal. Da fragt man sich doch gleich, ob die Welt noch ein Buch übers Testen braucht. Auch über JUnit und testgetriebene Entwicklung existieren bereits sehr gute Bücher (z.B. von Johannes Link oder Kent Beck). Den Unterschied finden wir im Untertitel zu Franks Buch: "Wie Software änderbar bleibt". Bei Frank geht es nicht primär darum, wie JUnit funktioniert und wie man die ganzen Probleme löst, die einem beim Testen mit JUnit so widerfahren (Datenbanken, Threads, Application-Server). Vielmehr geht es darum, wie man Software in der heutigen schnell-lebigen Zeit mit seinen agilen Vorgehensweisen entwickeln kann, ohne dass sie einem schon nach wenigen Monaten zusammenbricht. Testgetriebene Entwicklung ist lediglich das Hilfsmittel, dass Frank - mit Recht - dazu verwendet. Und so wundert es nicht, dass auch diskutiert wird, wie sich Refactoring und kontinuierliche Integration im Zusammenspiel mit testgetriebener Entwicklung entfalten und wie man mit Mock-Objekten die Komponenten seines Softwaresystems entkoppelt.
Der Abschnitt über Akzeptanztests am Buchende schlägt ebenfalls genau in diese Kerbe.
Insgesamt hat Frank ein Buch vorgelegt, dass nicht nur sehr verständlich geschrieben ist, sondern dass auch einen wichtigen eigenen Beitrag liefert.

Post bewerten