The long way round…

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.

I’m a big fan of wikis and as a company we use them extensively. The cost benefit ratio simply cannot be ignored. One person solves the problem, publishes the answer on the wiki for X number of people to apply and tweak as time goes by. The only real hit is on the person publishing the content in the first place. That ain’t going to change, but…

…traditional wikis tend to be hosted on a web server. This is both good and bad. The good is accessibility, the bad is the dreaded HTTP request/response and the loss of client-side interaction. Now I wouldn’t consider myself a lazy person, but as I get older I strive to do more with less. When I have to add content to the wiki, the first thing I do is sigh. Why? Because its going to take at least 10 client/server round trips to navigate to the place I need to be, and then to add/edit the page, preview it and save it. As a content provider this sucks for me. There just has to be something better.

Then I found tiddlywiki. Nice! A client-side, highly interactive, javascript on steroids, wiki in a single file. Yep. A single file that you can transport around with you anywhere. Now for personal wikis this is great. But for team based wikis we need some sort of server but without giving up on the flexibility and interative nature of tiddlywiki. This is future work.

There have been some great innovations with tiddlywiki. Take for example, this Getting Things Done site. A few more plugins here and there and we could do some really neat project-specific stuff. For example, user story plugins and project tracking tools. The navigation is cool and the ease of downloading the entire wiki is sublime! If you wanted to mess about with tiddlywiki I suggest reading the tutorial and hosting your site at tiddlyspot.com. And last but by no means least, brush up on those Javascript skills…

It’s that time again! Sell the house. We do this every 2-3 years to stay on our toes and just to do something different. People call us mad. Maybe. But its interesting to move to a completely new place, with a bunch of new neighbours, gossip and shops to get your head around and with the added bonus of leaving the less desirable people you happened to be positioned next to at your previous address. It’s all good fun.

Anyway, selling a house is all about applying the 6 P’s - Prior Planning Prevents Piss Poor Performance. And when someone says the word planning, I reach for my index cards. On each card we wrote the name of a room, plus non-rooms such as cellar, loft, garden and car. We stepped through house and brainstormed what tasks needed to be completed to best market each room. For example, remove pizza boxes (I can’t believe I still do this - grow up Cleve), clean the toilet (mental note - assign this one to the missus), paint ceiling, and so on. These were added to that room’s the index card. Once all the cards were completed, we sat down agreed effort estimates in undisturbed hours and cost in pounds sterling. We quickly added up the effort estimates and costs, and got a completion date and overall budget.

Now, a week into this and we are ahead of schedule. Sweet! And, having done this 4 times before, this is by far the most enjoyable prepare for sale experience we have ever had. Why? Because it is not ad-hoc like all the other times that we have done it. We know how much more we have to do before we are done. Basically, there are two piles of index card above our fireplace - the completed and not completed pile. A simple but clear visual reminder of outstanding work. Also, if I have a spare couple of hours, I trot downstairs, pick up a card and start work. No need to liase with the missus on what I should do or what she is working on - if the card is on the “not completed” pile - take it and do it! It’s that simple.

Another really interesting aspect to it is the budget. Because we are tracking estimates against actuals, and because we are currently underspending, we are able to hire workmen to do work we planned to do ourselves to bring the completion date in. This is proving to be very useful indeed.

Anyway, enough already. I’ll let you know how things are progressing in a couple of weeks time…

I would be the first to admit it. I’m a geek. I love technology. I think well written software is an absolute thing of beauty. There is no better feeling than being a member of team (coding solo is not really my bag) that cuts quality code that can be adapted to meet future (read as unplanned) requirements. That simply rocks my world.

That said, these days I’ve found hidden value in not being a part of the coding team - the engine. I’m no longer a part of the engine but more the oil in the engine. Basically, if there are guys that are better than you, the that best thing to do is let them get on with it. However, an engine needs tuning here and tweaking there to deliver the best results possible, in the shortest space of time. Every team needs oil, without it, things get stuck and engine stops performing. More to the point, you’re either oil or a part of the engine. You cannot be both, or something, somewhere will break!

So ask yourself, in your team, what are you - oil or part of the engine?

I’ve just come back off holiday with the missus and 3 kids. It ended up being a fanastic break, but started off as a right old howler! The middle kid, India, can be nightmare and morphed into a some demonic, adult munching, seven legged monster on day one of the holiday. That same night the missus and I discussed the issues and formulated plans to improve the situation. Day two was an improvement and again that night we revised our plans. Day three was even better and so on and so forth. Happy holidays…

When I got back from holiday it suddenly dawned on me that I was applying the stuff that I do when running software projects to my homelife. Sad, but true! There are many different names for this (not my sadness), but I like the term used within Crystal Clear - Reflective Improvement. It you think of the holiday as a release, then each day was an iteration within that release. Intra-day we were doing Reactive Improvement, bascially dealing with issues as and when they arose. Inter-day, we were doing Reflective Improvement.

You need a heathly dose of both reactive and reflective improvement. With reactive improvement, you are making tactical adjustments within an iteration to steer it to a successful conclusion. However, tactical adjustments are not as effective unless they are made within the context a strategy. The strategy defines objectives and success criteria, however formal or informal you wish to make them. Moreover, the strategy needs to be made outside of an iteration so that the team can discuss the issues as if looking down on the battlefield from the highest mountain, rather from in the frontline trenches.

The sad truth is that the majority of software projects I’ve encountered, I may be unlucky, deal purely in the reactive improvement and reflect only once as an post-project post mortem exercise. What the hell use is that? If I had I done that on holiday, India would surely have completely devoured by left big toe, and heaven knows what next.  But don’t worry, I’m fine…

Over last month or so, I gave a couple of lectures on software development to students at the Poznan University of Technology(PUT), Poland. PUT is a great place and the students are (refreshingly) very keen to learn. It was the students who asked to get electronic copies! Anyway here they are.

• The first lecture talked about the key differences between developing and delivering software
• The second lecture built on this to convey the things you do to professionally deliver software.

For those that didn’t attend, you should be able for the follow the main flow.  If not, ping me…

Enjoy.

I’m not agile, but I have agile tendencies. I’m not test-driven, but I am a firm believer in writing tests as you develop. Treat your tests as your source code keeps you honest and on your toes. So why the post? I’m starting yet another project and I wanted to give Test Driven Development (TDD) as shot. That’’s all.

Some background. The project we have is tight. No changes there. It has a couple of releases, that we have further broken down in iterations. We are currently in the second iteration of the first release. The first iteration was to provide a live end-to-end mock up of the web site we are developing for our client. As a proponent of user-centric design, I’m keen to get the application in front of the end-user as soon as is humanly possible. As a result, and as expected, the requirements shifted quite a bit after iteration one but we, customer and us - the team - are now happy with the screen flow. Major bonus point.

Given the project is heavily database focused and it requires us to connect to legacy data, the second iteration is all about domain modelling. The technology base is comprised of all the usual suspects being Java, Spring, Log4J and WebWork as the presentation layer. My task was to take the end-to-end mock up and write the first DAO. In doing so, it would bring Hibernate to the party. So I started by writing a test.

Step 1: Create the test!

Our application has auditing requirements. Write a test to store an auditable event into the database and verify that it can be retrieved at a later date.

Status:

• Test completed. Cannot compile code

Time Taken:

• 3 minutes

Current feedling:

• I’m in a dark place - this is going to take some fixing. I feel sick.

Step 2. Make the test compile

A number of classes were created such as the DAO and methods required to save and get back auditable events.
This amounted to the AuditableEventDao, the AuditableEvent POJO, an exception class to report errors and suitable documentation for these classes and interfaces.

Status:

• Code base compiles. Test fails.

Time Taken:

• 5 minutes

Current feeling:

• I feel dirty. This design feels all wrong. This test driven approach has pushed me down a certain design track. I don’t like being pushed.

Step 3. Refactor

Not happy with a couple of structures so I spend some time thinking and making things a bit neater and tidied up the comments in the process. Got the tests firing up within spring.

Status:

• Code base compiles. Test fails.

Time Taken:

• 5 minutes

Current feeling:

• Happier! A lot happier. I know where I’m going but still a long way from home. Time for a coffee.

Step 4. Make test succeed

This part was just plain tedious. Nasty. It was all infrastructural stuff. Getting the in-memory database running (hsqldb), writing the hbm files, configuring spring to work with hibernate, fixing the maven2 pom files, and so on. However, that said, having the test in place focussed the mind and swiftly pulled me back to the main run when i drifted off-piste experimenting with stuff.

Status:

• Code base compiles. Test succeeds

Time Taken:

• 15 minutes

Current feeling:

• Pretty good. I’m out of the tunnel…but not done.

Step 5. Refactor
This was the part I enjoyed the most. The tests are succeeding and I’m tinkering with the test framework. Making things better. Removing stuff here. Adding stuff there. Running the tests to check that I haven’t dropped the ball. It’s all good stuff.

Status:

• Code base compiles. Test succeeds. Added more tests.

Time Taken:

• 15 minutes

Current feeling:

• Smug. Game over. I want to write more tests…

Okay, I enjoyed myself. However, this is not the first time I’ve done this. Its just that I don’t do it all the time. More importantly, I don’t always write the test first. Will I going forward? I doubt it. But that would be the exception, rather than the rule. You can’t always develop in a TDD manner. You cannot have complete test coverage for your codebase. Any who says they have, I’d like to see it. But that doesn’t mean you cannot have a test framework that provides you with means to be make changes with confidence. For me, that’s the biggest win and the reason that we must move forward with writing more tests and if TDD helps in the battle, then I will use it where appropriate.