It’s been about 7-8 months since we started to serious pilot Fitnesse on a project. Looks like its turning the corner. Instead of developers driving it, the QA staff are starting to build out acceptance tests and add scenarios. It’s coming in very handy for testing a huge number of edits based on a positional file format.

I still wonder if we’ll evolve to tools beyond Fitnesse, but it’s starting to prove it’s value.

Chapter 3

Ruby Eye for the Java Guy

Rails For Java Developers

One of those silent chuckle to yourself moments.

Apparently JB’s entry on Wikipedia is up for deletion. He comments on the whole process of the debate around his deletion as:

The whole experience makes me feel like I’m in a room with people talking about me while not acknowledging my presence and not seeming to care what I think about that.

I can’t even believe there’s a debate around it. JB has obviously contributed much to unit testing, TDD, XP, and Agile in general. His book, JUnit Recipes, I still use as a reference when I run into a nasty testing problem. I re-read sections on testing EJBs just a few days ago and it was better than anything you can find by just googling around. He’s hosted workshops at XP conferences, run XP days, written a popular JUnit tutorial. I still love his post on BDD:

What is Behavior-Driven Development (BDD)?

It is Test-Driven Development (TDD) practiced correctly; nothing more.

For all that work he really doesn’t deserve this sort of treatment.

In number the great bulk of projects I see are small maintenance or minor enhancement projects. They’re done in a day or a week or two by a single developer. Adding anyone or even the overhead of something like Scrum is counter-productive.

My assumption has been you hand off the assignment and let the individual self-organize with say a business analyst, QA person, and maybe a PM. I wonder if they’re aren’t some emerging ideas on how to handle this from the Agile community. I know some people organize a maintenance list and just pull things off a prioritized backlog when they have downtime.

The best way to tell if your one developer project is Agile. The developer and business analyst meet the documentation requirement by emailing back and forth a one page or less document and the PM runs it around for signatures a bit before or sometimes a little after the code has been pushed out to production. The only thing we typically miss is some way to do an inspect and adapt cycle.

Developers have no love of estimates. They’ve been pinned in a corner by an estimate and beaten to a pulp. “But you said it would be done by Friday!”

I don’t have any problem with a developer being reluctant to give an estimate. I do have a problem with developers refusing to give estimates unless they have everything nailed down in a nice spec document and they’ve completed their design.

You can’t know everything when you give an estimate, hence the term. You base your estimate on breaking down the work you think will need to be done into small enough tasks and then build from there. You take into account risks and any historical information you have. Then you give an estimate.

The business has a right to expect this. In no way does this mean the estimate will play out exactly. If it does, likely it was an overestimate and the developer simply backed into it. Estimates will get adjusted by reality. As you get more information you can update estimates and give better future estimates. Scrum builds this into the process as you change your estimates every day. The important point is how many hours you have left on a task or whether you finished it, not whether the actual time you spent on a task lined up with your original estimate.

Rant done.