True iterations deliver value

Everyone wants to be iterative and incremental these days. Iterations are indeed nothing new; they have been around inside and outside of RUP and other methodologies for a long time and they show up again in SCRUM (called Sprints) and XP. Many projects claims to be iterative, but are they really?

In my view you are truly iterative only if you for each iteration go through the whole cycle of analysis, design, implementation, integration, test and deploy to really produce a high quality increment of the final system. Many projects I’ve seen claims to be iterative but tends to focus only on analysis and design in the first iteration, hence implicitly converting the iterations to phases in a good old fashioned waterfall.

The only way you get to benefit the true value of iterative development is to run through the whole cycle and collect feedback from everyone involved. Then you know how to do even better in your next iteration. As a Software Engineer we should really push for true iterations in our projects since that is the only way we are sure to be involved and able to give and receive early feedback.

Software Engineering Essential Reading 1 - Growing Object-Oriented Software, Guided by Tests

Under the title "Software Engineering Essential Reading" I plan to share short reviews of books and articles I find most useful and an essential read for every software engineer.

First up is an (in my opinion) outstanding book on Test Driven Development (TDD) written by Steve Freeman and Nat Pryce. The title is "Growing Object-Oriented Software, Guided by Tests" and, as the title suggests, this book is more about how to successfully build changeable and maintainable software using TDD than a technical book on a specific testing framework. Sure, through the book they are using jUnit 4.x and jMock2, but the book is not a go-through of framework features, rather it uses lots of example code to show how they "grow" (just like a gardener does with flowers) software. These frameworks just happens to be their favorite tools.

The book roughly consists of three parts:

1. First the authors go over their motivation for TDD and the principles and techniques they apply to both testing and OO-design and -implementation. Part of this is really heuristics to follow for a clean, readable and maintainable design of production code which also is greatly discusses in other books, but I like the fact that it is included here because it brings the whole picture of responsible software development rather than just explaining TDD ripped out of its context.
   
2. In the second part they go through a long (about 150 pages) example of "growing" an application using the principles an techniques from part 1. The example is very well done and easy to follow. In the beginning I felt it was very valuable, but at the end I thought it was running a bit long. But just as I was about to skip some pages the book went on into part three.
   
3. In the last part they wrap up and enforces their key ideas by going over their principles in more depth backed-up with the examples from part two. In many passages this part is so dense and right-to-the-spot that you have to pause a minute or so after each paragraph just to think over the truths that just were brought to you.

All in all, this is a truly great book and I would say it goes straight to the top of all SE-related books I've ever read. I strongly recommend anyone engaged in software development to get a copy.

Are you test infected?

That was the words a Finnish colleague used when first introducing me to unit testing using jUnit. It was back in 2002 when I had the pleasure of working with Capgemini Finland in a Helsinki-based project for about 18 months. The thought of writing test code to test my production code seemed good in theory since it would inevitably help me to find some bugs. But, wouldn’t it be at least twice as much code to write? And wouldn’t writing twice the amount of code make the whole project take twice the time to complete? I wasn’t in any way convinced that the practise of writing unit tests would make me a better developer.

I might be skeptical but I try hard not to be ignorant to new ideas. I tried writing a few tests and saw them pass without modifying my production code at all. I didn’t find any bugs, so what was the benefit of this? It didn’t mean I didn’t have any bugs in my code, it was just that since my design was not made with unit tests in mind I found it to hard to write any tests that really drove out the bugs. Instead we found them in systems testing and, like we were used to, had ourselves some late nights in-front of the debugger.

Since then there has been a good deal of writing and discussions on Test Driven Development (TDD) and I’ve been experimenting with both jUnit and TDD. Over the years I have come to solve more and more complex problems in my java designs and for some years I’ve been very reluctant to write or change any code without writing a test first to prove to myself what has to be done and that my code meets the requirement without introducing new bugs. Thanks to the excellent jUnit support in NetBeans, my IDE of choice, it isn’t a huge effort to write some extra code just to be sure the production code really works.

Now I’m happy about being test infected since I have proved to myself over and over again that I save time by writing tests as I design and code. In my experience it doesn’t take more than a few hours of coding, even on a very small project, to have a test fail unexpectedly and as soon as it does it means you have found a bug that you at some late point might have had to spend hours to debug.

So, if you are not yet test infected make sure to take a look at the xUnit framework for your language of choice. And if you are, please share your TDD experiences by commenting on this post.

Use Maven archetypes to create your source code structure

Maven (currently in version 3) comes with a great set of archetypes that can be used to create many of the most common source code projects. Instead of starting with an empty POM and setting up your own directory structure Maven can create it all for you. The POM is filled with settings for compiling, running and testing your empty project. It even contains dependency declarations for the most common frameworks and tools as specified by the archetype you choose to use.

IDEs generally have good support for Maven projects. In NetBeans, my IDE of choice, Maven projects are first class citizens. No conversion is needed, the project can be opened right away without any IDE-specific files being created that pollute the source directories. In the current stable version of NetBeans (6.9.1) Maven 2 is used. Since I wanted to run on Maven 3 I choose to create my Maven project at the command line and then open it up in NetBeans. NetBeans comes with wizards for creating projects, but when using it I ended up with a strange mix between the Maven 2 support in NetBeans and my installed Maven 3 runtime. Anyway using Maven direct from the command line feels better since I'm planning on building my project on Hudson later on.

In my example I created a project for a simple Scala application which out-of-the-box includes directories for production code and test code, a stub application-class and a POM with test time dependencies for JUnit, ScalaTest and Specs. This gives me a very valuable set-up with very little effort. Only thing I needed  to do was to move into the directory where I wanted the project to be created and type:

mvn archetype:generate

This command starts up an interactive session where I'm allowed to choose among a really large set of archetypes and then enter the unique identifiers for the project needed by Maven (GroupId and ArtifactId). And that's all! Now the project is ready to build and install into the local Maven repository. Of course, it doesn't do much yet... But I really recommend you to have a look at what Maven archetypes has to offer next time you are starting up a new source code project.