Akzeptanztests mit FIT

Es gibt seit kurzem ein Buch über Akzeptanztests mit dem Open-Source-Framework FIT. Das Buch deckt nicht nur FIT ab, sondern auch die Aufsätze Fitnesse und Fit-Library.
Das Buch zeigt anschaulich, wie ausgehend von den umgangssprachlichen Anforderungen des Kunden einfach FIT-Tests entwickelt werden können, die sowohl für den Kunden/die Anwender wie auch die Softwareentwickler verständlich und aussagekräftig sind.
Ich finde die Grundidee von FIT bestechend, Tests als HTML-Texte zu beschreiben. In HTML-Tabellen befinden sich die eigentlichen Tests, im Text drumherum erläuternde Beschreibungen. FIT stellt Hilfsklassen zur Verfügung, mit denen die HTML-Tabellen einfach ausgelesen und die Testergebnisse in die Tabellen zurückgeschrieben werden können.
Neben der gemeinsamen Kommunikationsbasis zwischen Kunden und Entwicklern hat FIT auch einen ganz interessanten Effekt auf die Systemarchitektur. Wird FIT nach dem Test-First-Ansatz verwendet, führt es zu einem sprechenden Entwurf. Umgekehrt deckt FIT in einem Test-Last-Ansatz Schwachstellen im Entwurf auf: Immer wenn die programmierten Fixture-Klassen umständlich werden, liegt Refactoring-Bedarf vor.

Post bewerten

Zweite Auflage erschienen: Wolf, Roock, Lippert: eXtreme Programming

Inzwischen ist die zweite Auflage des Buches "eXtreme Programming" erschienen, dass ich zusammen mit Henning Wolf und Martin Lippert geschrieben habe.
Insgesamt haben wir an dem Buch ziemlich viel verändert. Neben kurzen Skizzen anderer agiler Methoden (Scrum, Industrial XP, Feature-Driven-Development, Eclipse Entwicklungsprozess und V-Modell XT) haben wir den Bereich rund um die Vertragsgestaltung deutlich erweitert und auch dem oft vernachlässigten Thema der Explorationsphase ein eigenes Kapitel gewidmet.
Direkt bei Amazon kaufen.

Post bewerten

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

Erst Schreiben, dann tun...

In einem größeren Projekt arbeite ich als Ürojektleiter für drei Teilprojekte. Da komme ich nicht mehr selbst zum Programmieren. Vielmehr gehören Abstimmungen mit diversen Kunden, Tracking, Teambildung, Abrechnungsgefummel etc. zu meinen Aufgaben. Um herausfinden, ob ich was von meinen Tätigkeiten sinnvoll delegieren kann, habe ich jetzt eine Weile lang ein Log-Buch geführt. In dem Log-Buch habe ich jeweils mit Uhrzeit kurz aufgeschrieben, was ich gemacht habe. Die Log-Buch-Einträge sind zwischen 3 Minuten ("Smalltalk mit Entwickler XYZ") und 3 Stunden ("Releaseplanungsmeeting für ABC") lang.
Dabei habe ich ein paar interessante Dinge gelernt:

1. Ich mache viel zu selten Pause.
   
2. Das Führen des Log-Buchs ist fast kein Overhead (das hatte ich zunächst befürchtet).
   
3. Ich habe irgendwann angefangen, erst aufzuschreiben, was ich als nächstes tun werde und dann habe ich es getan. Das diszipliniert ungemein. Kein rumgetrödel mehr, kein E-Mail-Checken alle 15 Minuten, kein planloses Browsen im Internet. Das hat zu einer deutlichen Effizienzsteigerung bei meiner eigenen Arbeit geführt. Allerdings ist das auch anstrengender. Mehrere 10-Stunden-Tage am Stück kann ich so nicht durchhalten. Brauche ich jetzt aber auch nicht mehr. Mal sehen, wie sich diese Technik für mich in der Zukunft weiter bewährt.
   

Post bewerten

Verantwortung in der Softwareentwicklung

Das kennt man als Softwareentwickler: Der Chef oder Projektleiter kommt ins Büro und braucht unbedingt ganz schnell noch Feature XYZ für das anstehende Release. Also bauen die Entwickler das geforderte Feature mehr schlecht als recht ein. Es tut ungefähr das, was gefordert ist. Die interne Struktur ist aber äußerst bescheiden. Theoretisch kann man die interne Qualität später bereinigen. Es weiß aber jeder, dass man die Zeit dafür nicht bekommt. Also bleibt alles, wie es ist und das System degeneriert Stück für Stück. Für die meisten Entwickler ist das der unvermeidliche Gang der Dinge.
Die Entwickler sind also die Opfer ihrer chaotischen Chefs. Möglich. Allerdings ist diese Sichtweise weder nützlich noch ermutigend. Ich jedenfalls sehe mich ungern als Opfer. Und die Psychologen lehren uns, dass wir andere Menschen nicht ändern können. Wir können nur unser eigenes Verhalten ändern. Also brauchen wir gar nicht erst darauf zu hoffen, dass unsere Chefs zur Vernunft kommen. Was also können wir als Entwickler tun, um unsere Situation zu verbessern?
Ich schlage vor, dass Entwickler Verantwortung für ihre Arbeit übernehmen. Kein Entwickler darf Code programmieren, der seinen eigenen Qualitätsansprüchen nicht genügt. Auch dann nicht, wenn ein Chef oder Projektleiter Druck ausübt. Häufig bekommen die Chefs/Projektleiter dadurch genau das Feedback, dass ihnen bisher gefehlt hat. Sie konnten ja gar nicht einschätzen, wie stark sich ihre Sonderwünsche auf die interne Qualität des Systems ausgewirkt haben.
Und was ist, wenn der Chef/Projektleiter unbedingt auf der Quick-Hack-Umsetzung seiner Features besteht? Dann bedeutet das einfach nur, dass Entwickler und Chef/Projektleiter nicht zusammenarbeiten können.

Post bewerten

Ruby vs. Java

Ruby on Rails is a web programming framework written in a dynamic oo programming language called Ruby. Ruby exists for quite some time but with Ruby on Rails it was hyped during the last months.
There are some key features that make Ruby attractive:

• No compile time since it is interpreted.
  
• Compact syntax.
  
• Powerful reflection.
  

I was always a fan of statically typed languages like Java. With this background there are drawbacks to the Ruby approach:

• You can't use a compiler to find type errors.
  
• By reading source code it is hard to find out what type an object might have.
  
• There are nearly no refactoring tools for Ruby available.
  
• Ruby has a de facto standard for web applications (Ruby on Rails) but only poor non-standard support for rich client destop applications.
  

But also Java has its drawbacks. After having several years of experience with large J2EE projects I these drawbacks became clearer to me.

• Although some Java IDEs can compile incrementally, recompilation of large parts of the project is often neccessary and slow.
  
• Java programs are full of type casts breaking type safety. That mighth change with the generics of Java 5.
  
• With J2EE you need lots of hard to understand XML configuration.
  
• The XML configuration files break type safety. The compiler becomes less and less useful.
  
• The refactoring support for XML configuration files is quite poor in the moment.
  
• Java needs much more code and configuation than Ruby. Here is a comparison. In that comparison the Ruby application also is faster than the Java application.
  

To me the obvious difference between Ruby and Java always was type checking. Ruby does no automatic type checking. Java does automatic type checking during compile time. Therefore Java can find more bugs than Ruby. Now I no longer believe that type checking is the point. As I wrote above type checking becomes less useful in Java systems. In Ruby and in Java a lot of real value type checking is done in unit tests. Perhaps the type checking in Ruby systems is even stronger than in Java systems. In a Ruby system the programmer knows that he has to write unit tests. In Java it seems optional to a lot of developers to write unit tests - do they think that the compile time checkings are sufficient?

So, what are the key differences between Ruby and Java in real world projects? I think there a three main aspects:

• Ruby programs are more compact than Java programs. Less lines of code means less programming errors. That is a clear advantage for Ruby.
  
• Refactoring is now state of the art. Java IDEs have powerful refactoring tools. Ruby has poor refactoring support und in some aspects the Ruby refactoring support will stay weak. It has the Smalltalk problem that you never now on what object a method will be called. Therefore renaming a method has to rename all methods with the same name. Therefore a big plus for Java now. But hopefully Ruby refactoring tools will evolve.
  
• Source code is written once and read many times. Therefore source code has to be easy to understand. I find it helpful to know what type of object the programmer of a method expects as a parameter. In Java it is easy. The type is declared in the method signature. In Ruby programs it is often hard to find out what the programmer really expected. Conventions help but I have the feeling that the Java way is superior here.
  

So, what has Ruby to do to gain world domination? Here are my 2 cents:

• Ruby needs a refactoring tool. At least with "Rename Class", "Rename Method", "Rename Attribute", "Extract Method" and "Inline Method". The last one might sound a bit special but Tammo Freese described the real power of the "Inline Method" refactoring in a presentation at the XP 2003 conference. We used his ideas in our Refactoring Book.
  
• Ruby needs at least a convention used by everyone to annotate the expected type of an object. It would be even better to check the type at runtime. Perhaps there should be a language extension for annotating dynamic type checks in an elegant standard way. This information could be used by refactoring tools also to be more specific when refactoring methods.
  

Post bewerten

JUnit 4.0 ante portas

Frank Westphal wrote a good overview about the new features of JUnit 4.0 (in german language only): http://www.frankwestphal.de/JUnit4.0.html

Post bewerten

Refactorings in großen Projekten

Martin Lippert and I have written a book about doing Refactorings in large projects. The book is available in german from dpunkt.

The Javamagazin has reviewed the book in July 2005: "Fazit: Das Buch ist auch ohne große Vorkenntnisse als Einstieg in das Thema Refactoring und Smells hervorragend geeignet."

Post bewerten

UML-Shapes für Visio

One of the tools I like most is Visio. Visio comes with a set of UML shapes. Unfortunately these shapes try to be intelligent creating a lot of hurdels. Therefore I prefer less intelligent flexible to use shapes like these: http://www.phruby.com/stencildownload.html

Post bewerten

Tonabnehmer-Podcast by Frank Westphal: Agile Software Development

Frank Westphal puts interviews with people doing agile projects on his web: Tonabnehmer. Very interesting. Put the mp3 on your MP3 player and consume it in the subway. The interviews are done in german language.

Post bewerten

eXPlain Project Management Tool

eXPlain is a story card management system for agile projects, namely eXtreme Programming. In contrast with XPlanner eXPlain supports effort estimations in effort points (not person hours). Moreover eXPlain has a much smaller than XPlanner. All the XPlanner features I never used, aren't there in eXPlain.
And eXPlain is written in Ruby and is therfore ridiculous small in code size. Ruby seems to be the upcoming star for web applications.

Post bewerten

Weblog for IT-Managers

it-agile has started a (german) weblog addressed at IT-Managers (project manager, head of it department etc.): http://managerblog.it-agile.de

Post bewerten

Luntbuild

Luntbuild is a new build process management tool (like Cruise-Control). It has a nice and easy to use web interface (you don't have to edit any files). We started to use it in one project and got promising results.
The most important drawback in contrast with Cruise-Control is the missing Quiet-Time-Period for CVS. In projects with many concurrent check-ins that use CVS the missing feature may cause some trouble.

P.S.: It seems that the current Luntbuild download has a little bug (since it requires Starbase classes). The bug database of Luntbuild has hints on how to fix the problem without programming.

Post bewerten

Cobertura

Cobertura is a fork of the GNU version of JCoverage. In contrast with GNU JCoverage there is some development activity at Cobertura. Some long known bugs in JCoverage are fixed in Cobertura now (e.g. the problems occurring when more than some 100 files had to be instrumented).
There where also problems when we tried to use XRadar with GNU JCoverage which are fixed in Cobertura now.
In one project we switched from JCoverage to Coberatura and it worked fine.

Post bewerten

Evil Singletons

I have built quite a lot systems as a developer and I have seen much more systems as a consultant. Now I'm strongly convinced that Singletons are evil. Uncle Bob has written a nice article on Singletons.

Post bewerten

Weblog for Developers at it-agile

it-agile has started a weblog targeted at developers: http://entwicklerblog.it-agile.de (german only).

Post bewerten

New Job

I changed jobs at 01-jan-2005. Now I work as an IT consultant for it-agile. it-agile offers agile software development and consulting / training for agile methods like eXtreme Programming. My new EMail address at it-agile is "stefan DOT roock AT it-agile DOT de".

Post bewerten