Pols Consulting

I enjoyed reading Keith Braithwaite’s post on tests and gauges.  I like the way Keith uses the the metaphor of gauges in metalwork to describe Fit style tests:

 You don’t work anything out from a gauge.  What you do is apply it to see if the workpiece is within tolerance or not.  And then you trim off, or build a bit up, or bend it a bit more, or whatever, a re-apply the gauge.  And repeat.

I agree with Keith.  The fit tests I write are business facing and for the benefit of the business customer.

On a recent project our customer got so enthusiastic about our fit tests he got extremely upset when I implemented a story without a fit test.  He refused to let the system go live until we had the fit test in place.

The story in question was very technical and involved sending a particular xml message to an external system. We just could not work out what a fit test would look like for this type of requirement.  Placing the expected xml message, with all it’s gory detail,  in the fit test would not have been helpful as this is a technical artefact and of no interest to the business.  We could not work out what to do.  The customer was not around to discuss this so I just went ahead and implemented the story (very naughty!).

What the Customer wanted was to be sure that we were sending the correct product information in the xml message.  To resolve the issue, I suggested that we have a Fit test that shows how the product attributes get mapped onto the xml message using xpath; although I still thought this was too technical for a business user.

We gave the Customer a couple of links to explain what xpath was so he could explore if this was a good solution for him.   To my amazement, he was delighted with xpath (I now know who to turn to when I have an problem with xpath) and filled in the fit test.

The interesting bit for me (and why I’m posting it on the blog) is that as soon as he knew what the message looked like and how it was structured, he realised that it did not really support the business - we were sending information that was outside our scope of our work and should have been supplied by another system.  He was also skeptical about the speed the external team could add new products due to the complex nature of the xml.

Most agile people tell this story to think we have the “perfect customer”!

Steve Freeman had an interesting post in which he wondered if there was a tendency for geeks to be B-people?

Well, I hate going to bed and hate getting up in the morning. So it must be true! It could also explain why there is so much bad software in the city (they tend to start really early in the morning!)

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.

I noticed an interesting discussion on the IXP mailing list about pair programming with developers during an interview. I was surprised by the number of people who thought it was a bad idea.

I have done a lot interviewing for various companies and one of the best ways to find out the beliefs and values of a software developer is to look at their code. The best way to know what someone is like to work with is to work with them! This is why I really like pair programming interviews. It’s one of the best interview techniques I know.

Another nice feature of a pair-programming interview is the continual conversation you have with the candidate. It provides you with ample opportunities to ask sensible questions about the code you are writing. This gives the candidate a better understanding of why you are asking the question. There’s nothing worse than crazy interview questions that make no sense!

There are certain things you have to be aware of. You have to be very good at putting people at ease. You need to explain why you are running the interview like this. Some people get very nervous at an interview. You have to treat it as if you are pairing with a colleague. If people get stuck, you should help them out.

An interview is a two way process . The candidate also gets a much more realistic idea of what it would be like being in the team. They see what it’s like working with the team and experience the development environment first hand.

Jennitta Andrea has published a wonderful experience report in http://www.stickyminds.com/BetterSoftware called The Case of the Missing Fingerprint.

Well worth reading. Nice work.

The team I’m working width decided to organise their Christmas party and sent out the following email invite.

This apparently innocent email triggered the following amusing sponsored links!

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!

Here is a nice podcast from Jason Fried from 37Signals.com

He had an interesting spin on co-location. I always thought distance hurts, and having everyone working together in the same location was critical. Jason argues that if you can’t explain a design or a business strategy using IM or Skipe then it’s too complicated and you should choose something simpler. This made me re-think my views on this.

It’s a really interesting point of view. I have been mulling this over in my mind for a few days now. I wonder what impact people’s learning style has on this? I’m very visual, I really like being able to jump up and draw pictures with collegues around a white board. I wonder if Jason is more of a words person?

Norm Kerth gave a great talk on retrospectives at SPA2006.

I’ve been a fan of retrospectives for a long time. The interesting thing for me was Norm’s description of Kick-Off Retrospectives.

I typically do this when teams are formed for a specific project (and don’t stay together once it has been completed). They basically run a retrospective to set the scene for how the team wants to operate.

The subtlety I had missed is that you can use the future perfect tense when asking the questions. You can ask people to imagine that this is the retrospective at the end of the project and ask them “What was so good about this project that you would like to repeat on future projects?” This sets the scene for how the team want to operate.

While on the subject of retrospectives, here is an interesting article by Ester Derby on keeping retrospectives fresh

Luke Hohmann has started blogging. Fantastic!

I like this observation:

One of the points that Don made in his presentation was that being a true visionary can, at times, be a curse. When a visionary holds too tightly to his or her vision, they are often overtaken by the world that is happening around them. Furthermore, a visionary can be a bit depressing, as no matter what someone else does, they claim that it isn’t good enough. And that’s simply not true.