Pols Consulting

As a follow up to my post on pair programming based interviews, I noticed this on a recent job advert:

In chess it is possible to place eight queens on a board so that no one queen can be taken by any other. Write a program to determine all such possible arrangements for all eight. I am not looking for a Chess Games Developer. I am looking for Java Developers who have the OOA and OOD skills to solve this problem….

Which one would you prefer (to receive if going for an interview, or to use to find a good candidate to work in your team)? A test that’s abstract and has nothing to do with the work involved, or one that that involves doing the job you are interviewing for?

I wonder if they have run this test on all of their existing staff to see if their is any useful correlation.

Nat Pryce, Romilly Cocking and I have just run a session on Test Driven Development using the new (so new, it has only just been released) JMock 2.0 library at SPA2007.

We got a lot of positive feedback, so I thought I would share the slides and some example code that we developed for the session.

Organise the Fit Tests around your iteration’s stories

I like to take small baby steps when I write software. It makes life easy. I don’t have to merge very much code, I get regular closure on what I’m doing, I don’t have to carry too much around in my head, and I can discard mistakes without loosing too much work.

Automated acceptance tests, such as Fit, can throw a throw a spanner in the works. I like to explore the problem by writing the Fit test with a domain expert before I start writing any code. I treat the acceptance test(s) as a definition of success. Before I start work on a new feature I need to understand how I’ll know when the Customer/Domain Expert is happy with what I have done. I flesh out the answer in the fit test (I often have several Fit tests exploring different aspects of the story).

Great, but Fit tests are course grained in nature. I typically make at least 20 baby steps (source code commits) before a story is complete. I don’t want to commit the Fit test before I start writing code as the Fit test will fail and break the build. Not good. I don’t want to wait until the fit test is complete as that will loose all the advantages of developing in baby steps.

Some teams use different directories to distinguish between the Fit tests that have been completed and should pass, and those that are currently being worked on. The tests get moved around when they have been completed. I guess that solves the baby steps problem, but I’ve never liked moving files around to indicate completion and it’s still hard to see how the Fit tests relate to the originating Customer Stories.

William Jones has a much nicer solution with his Agilifier project.

There is not much documentation at the moment (well, it is opensource!), so I’ll give you a quick overview.

• You group the Fit tests around the stories they are associated with. All the tests associated with a story are contained in a directory. You place the original story in the story.txt file. You simply add your Fit test files to the directory.
• You use test suites to make the distinction between the previously completed tests (i.e. we have broken something if they don’t pass - and should fail the build!), the tests associated with the current iteration (i.e. these provide a progress bar of the current iteration) and those tests an individual (or pair) are currently working on. The suites are simple text files containing the tests to be included in the suite.
• Agilifier runs the test suites and glues the story and Fit tests together in a nice html report.

Download it and give it a try. You should be able to figure it out from it’s own acceptance tests!

Ooooh, this year’s XPDay looks like it’s going to be a good one - it just keeps getting better and better.

Steve Freeman and I are running a session on various techniques for exploring customer requirements. It’s based on our experience in applying some of Dave Snowden’s and Luke Hohmann’s ideas on our recent projects.

A software group is best measured by its customers’ success. Understanding what they really need is critical, but customers are human too which means that they’re fallible. Customers can’t always tell you what they want because sometimes they don’t know themselves, so asking them to rank requirements or write stories might not be the best place to start. This workshop presents techniques for working with customers and other stakeholders to help them understand the context and goals of a project or product. It describes a range of techniques such as “Speedboat”, “Product Box”, “Butterfly Stamping”, and “Give ‘em a jacuzzi” and runs two of them as exercises.

I have always been frustrated at how slow ant is at running my tests.  If I run my tests in Intellij it takes around 4 minutes to run 1300 tests.  The same tests in ant take over 12 minutes.

This is not such a big deal when I’m developing as I run them all in Intellij.  The problem is that the Continuous Integration server runs ant.  If the automatic build takes too long following a commit, I will have started working on something else.

I was telling people this as a recent Agile Summer School that Duncan Pierce and I ran. Justin Forder did some digging around and found the magic forkmode attribute…

You normally fork a new JVM to run the tests since it isolates your tests from Ant’s environment (which places a lot of libraries on the classloader).  The reason it’s slow is that the default behavior is to fork a new JVM for each test case class.  That’s a lot of forking.

It turns out that Ant 1.6.2 introduced a new junit task attribute called “forkmode“. If you set it to “once“, Ant will fork a single Java VM for all your tests classes.

Fantastic, the build server is now running all the tests in 6 minutes (it’s not as fast as my development machine).

Thanks to Justin Forder for pointing this out to me.   See Stefan Bodewig’s Weblog for more info

Continuing on the theme of breaking the self imposed rules I heard a wonderful story about a team working in an environment that involved a customer requirement to provide an audit trail of all project design decisions.

This was a real rule.

Many teams would interpret this as a requirement to have lots of heavy documentation and associated traceability. This would have been a self imposed rule.

This team solved the requirement in a wonderfully low energy way. They simply attached a long roll of brown butcher’s paper around the room. Whenever people on the team made a decision, they made a note of it on the paper, dated it and signed it. This acted as a short term information radiator of team decisions. Once it was full, they rolled it up, marked it with the date range and filled in it the corner of the room.

The auditor loved it as it was quick and easy to see what was happening over time.

I had an interesting conversation while running an agile training course with Alistair Cockburn. He has a common theme running through his books – that agile is cheating legally to win.

When you explain Agile to people you often get the response, “but that’s cheating!”

Our conversation with the class was about which rules are real rules (i.e. those imposed by the customer, or legal bodies) and which rules are ones the teams have imposed on themselves without realising it? When you run a retrospective on your process, you are trying to find ways of making things better (which rules you can break legally!).

When you start thinking in terms of real rules and self imposed rules it really opens up opportunities. Try it as let me know how it goes.

The Inversion Of Control architecture pattern has been gaining popularity, but I never expected the need for inspectors…

Thanks to William Jones for pointing me at this…

While blogging about the latest edition of Private Eye, I came across the following humorous ditty (page 4):

For several days during December graduates trying to glean information on the company’s UK recruitment programme were met with a plain white screen bearing the message “Unfortunatley we are currently experiencing some technical difficulties with our website and are unable to accept on-line applications.

It’s good to see that EDS eat their own dog food and use their own support services!

Chris Matts (the other half of the Agile Business Coach has just published a new paper on the joys of negative feedback: Encouraging the “Right Stuff”  (PDF format)