The long way round…

I have moved my blog to http://www.clevegibbon.com/blog. I done this because I am playing around with new plugins and stuff and I cannot do that safely on the corporate blog.

It’s been a long time since I’ve had time to post anything.  A lot has happened, most notably I moved house.  How painful is that! Being offline for 2 whole days really hurt me.  But I’m back with a fatter pipe providing me with copius amounts of bandwidth.

Anyway, during my downtime I read a great article by Alistair Cockburn on “Are iterations hazardous to your project?” And yet again Alistair is spot on.  There are many nuggets in this paper but by far the one that rings home for me is the age old problem of clients not having the time to accept iteration deliverables.  With no feedback, where’s the value.  Agile development is about delivering value.  If you are not doing that, you are doing iterative development NOT agile development.

Another funny thing Alistair alludes to is are the macho agilists.  I’ve come across a number of these and I had to laugh out loud on the issue of iteration length.  Alistair is spot on with macho agilists opting for very short iteration cycles.  Don’t get me wrong, sometimes very short iterations are the right thing to do in certain contexts, but in others i’ve seen them used to by macho boys to demonstrate experience and knowledge over an unworthy (read as less experienced) agile opponents (read as team members) .   

Anyway, I recommend taking 10 minutes out of your day to read this article…

I used Groovy a couple of years back and loved it.  But then did nothing with it.  Then Graeme Rocher, author of The Definitive Guide to Grails, came over to our offices to deliver a course on test-driven development.  After that I got interested in Grails - a web framework that brings the coding by conventions paradigm to Groovy to simplify application development. 

So I refreshed my memory with Groovy by reading the following:

• All the documentation at the groovy web site

Now, ready to flex my Groovy muscles I downloaded and installed:

•  The Eclipse groovy plugin. 

Then with that installed I ran through numerous examples.  But before you do anything, I think you simply have to read about Closures.  To my mind, one of the most powerful and well implemented features within Groovy. 

So I’m up and away with Groovy, then next logical step is to see how easy it is to integrate with some legacy Java applications that I have wandering around.  Also, just how easy is it to debug in and is the Eclipse plugin up to it. 

Sorry, been offline for a bit with project work. Anyway, we are entering a new phase of a project that is heavy geared towards web services and interoperability between the .NET and Java platforms. After a little bit of digging around I found this very useful utility, SoapUI, that people like, so I gave it a go.

Not bad. Not bad at all. For the .NET guys, bear with the Java looking GUI and look to its ability to quickly and easily test web services.

Neat.

Okay, I finished Agile Project Management with Scrum by Ken Schwaber. Damned fine book that I highly recommend. The neat thing about this book is that is it defines Scrum, start to finish within a single chapter, that being chapter 1. The remaining chapters demonstrate exactly what Scrum is with real life examples of projects applying Scrum: the good, the bad and the ugly. Ken pull this off nicely.

I am still coming down on the side of Scrum with a bit of XP, as opposed to XP with a bit of Scrum. The simplicity of Scrum, its clear and concise rules and practices, fit with the way I tend to run projects. I don’t know enough of about XP in practice, so I’ve decided to attend XPDay this November. Also, we just had the pleasure of Rachel Davies, the now chair of Software Practice Advancement 2007 (formerly OT) come out to our offices to run a number of XP sessions. Interesting stuff…

3 years ago I was contracted by ABN to build what ending up being a sales portal for their Fixed Income Business Unit. The team started out with just me on the sales side. I was both the Technical Architect and Project Manager and the team grew to 15-20 people by the time I left. So why I am telling you this?

I left because the team structure had evolved into something that I couldn’t work within. I loved the people, but when things are better without you, than with, you walk away. In the beginning, as the team grew I mentored and coached, held frequent team meetings to synchronise knowledge and status, we delivered frequently (despite clearcase) and were quite proud of our continuous integration build environment. The business defined value. We delivered it. The team structure was flat. Work was fun.

Then the business threw more work at us. Management reacted by adding more levels of management (sigh!). The team moved from a flat to a hierarchical structure. The once fluid communication with the customer stopped. There was a layer between us and them. My project manager hat was removed. I was purely technical architecture now (”thank’s very much cleve, we’ll take it from here…”). The team stopped having meetings. The team became individuals. The individuals reported individually to the new project manager. The team became dysfunctional in some respects but we had to continue to deliver software. That’s what we do. We just did it in a different way.

During this change in team structure, I fought to maintain the close collaboration we had built up with the customer. I fought to protect the team dynamic. I failed. The islands of developers (read as component groups) were formed.

Currently, I’m half way through a book by Ken Schwaber called Agile Project Management with Scrum. It is the book that I wish I had known about to give to my project management to read, to understand what I was fighting for and why it was so important to both the business and development teams. I basically failed to articulate the guidelines, practices and rules of Scrum in a way that made sense to both of us.

Ken, I take my hat off to you. The more I read about Scrum, its case studies and how ScrumMasters have applied it to the thousands of projects out there, the better I feel. I always thought it was mad to fight complexity (software) with complexity (high ceremony process and/or methodologies). Although outwardly Scrum appears simple (this is good a thing), its conceptual rivers run deep. I am looking forward to learning how deep…

After a day of getting FIT I was able to run the FitNesse wiki and poke around a bit and run some more acceptance tests.  This I found very interesting and quite impressive really.  It was truly simple.  So how do I write acceptance tests for my .NET applications.

The first step is understanding how a java based FitNesse wiki ran my .NET acceptance suites.  Fortunately this was pretty easy.  Under the fitnesse install directory their is a subdirectory called dotnet.  It the dotnet directory there is a .NET implementation of the FitServer that consumes test tables and communicates back results.  All we have to do in our wiki pages to tell FitNesse to use the .NET FitServer instead of the Java one to run our acception tests.  This is done by placing the following at the top of the wiki page that you write the acceptance test in:

!define COMMAND_PATTERN {%m %p}
!define TEST_RUNNER {dotnet\FitServer.exe}
!define PATH_SEPARATOR {;}
!path dotnet\*.dll

That’s it.  Then add the following test table to your page as well

!|eg.ArithmeticColumnFixture|
|x|y|plus()|
|10 |2 |12 |
|12 |3 |15 |
|100 |4 |104 |

The syntax is simple enough. 

• Line 1:  The test fixture to run, with eg.ArithmeticColumnFixture being a fully qualified class name 
• Line 2:  These are public members on the test fixture in first two columns, and the final column is the method that is called to perform the test.
• Line 3-5: These values are assigned to the test fixture members and  the plus() called.

This page shows an example test table as it is rendered within the FitNesse.  Notice how FitNesse displays the .NET settings of the page.

To run the test, click the Test button that is in top left hand corner of the menu items.  (Note that to make a page a Test, select properties from the menu items and choose the Test option box.)

After you run the test, the results are displayed.

This works okay, now how do you write you own.  Take the following steps:

• Open your VS Studio Project with the code that you want to test.
• Write your acceptance test fixture code
• Have your project *.dlls copied into the FitNesse/dotnet directory (Post Build Events in VStudio are good for this).
• Write you test table wiki page and run.

One thing to note.  I was build using VS Studio 2005 and FitNesse was having problems finding classes within my assembly files.  To fix this I had to checkout the latest FitNesse.DotNet from the trunk and build it (You need NAnt). 

• svn co https://svn.sourceforge.net/svnroot/fitnessedotnet/trunk fitnessedotnet

Once done, I copied the required binaries into the FitNesse\dotnet directory and everything worked fine.

One of the early things on a project to get sorted is who is going to be performing acceptance tests and how are they going to be written and executed? Just so we’re clear, acceptance tests are what the customer executes to verify what you (the team) have delivered is what they (the customer) asked for? If not, its back to the old drawing board.

FIT is a Framework for Integrated Tests that was created by Ward Cunningham and is gaining popularity. FIT simply consumes test tables, where a test table is a bunch of acceptance tests with input values and expected results. The trick is to provide test tables in tools that customers use as part of the every day life, and what is more everyday than Word and/or the Web.

Focusing on the Web side of things, FitNesse is a software testing tool that front ends FIT with a wiki. In Fitnesse the customer can write acceptance tests as simple tables that can be executed. These executable test tables call the software that you wish to be accepted by the customer.

Installing Fitnesse

Hmmm. This wasn’t so hard, simply do the following:

• Download the latest zip and unpack into a directory of your choice.

At the time of writing, the latest zip was fitnesse20060719.zip. Note that FitNesse is a wiki implemented in java. However, it does support the running of acceptance tests for .NET. Now once unpacked, step into the root directory and issue the following:

• run -p 8888

This will display a little text to say all is well. Now traverse to the FitNesse wiki at:

• http://localhost:8888/

Here are a couple of quick links you should try:

• http://localhost:8888/FitNesse [ lists all pages within the wiki ]
• http://localhost:8888/FitNesse.DotNet [ the .NET page ]
• http://localhost:8888/FitNesse.DotNet.SuiteAcceptanceTests

The last one is very interesting because in the left hand menu, you’ll see the top menu item is Suite. Click this to run all the .NET acceptance tests. Note, that you need .NET installed on your Windows machine.

I’m tired. Tomorrow I’ll step through the problems I had trying to get my own acceptance tests running against inside Fitnesse.

This was a strange book.  I simply never got into it.  If you are new to Agile and/or having problems selling Agile into your organisation then its worth a look.  It has a lot of evidence for why Iterative and Incremental Development (IID) works.   Also, if you want a reference to how different agile methods such as XP, SCRUM, Evo, and the Unified Process (UP) compare/integrate with one another then maybe worth a look.  It’s strange, it was a book I didn’t learnt anything new from but it had tons of information and/or content in.  I dunno, maybe its because I was on a course given my Craig Larman (I learnt tons there) last week and everything was a bit too fresh… 

One of the best ways to learn a new language for me is to write a load of tests that demonstrate how particular parts of the lanugage and/or platform work. For VisualStudio 2005, I wanted to do this without paying for the priviledge, so this ruled out:

1. TestDriven.NET that is suppose to provide good test integration with VS.NET.
2. Visual Studio Team Suite (VSTS) built in test framework. See what Charlie Poole, a member of NUnit team has to say about this.

So I installed NUnit and took the following steps within VisualStudio:

1. Created a new VS Solution with a C# Library project called basics.
2. Right clicked on the basics project and set the startup external program to be NUNIT_HOME/bin/nunit-gui.exe

Once done, everytime I run in debug it fires up the nunit gui and I can select my test and run it. I am now in a position to test and debug anything within the .NET platform that I can condense down into a simple test. Nice!

Again, that wasn’t so bad…