A rather humorous exchange happened today at a standup:

The subtext is this is on a project with only a handful of unit tests at all. Of course it’s both in a portal and using JSF which makes setting up the context to test something like a JSF backing bean a major pain. Since they haven’t really had many tests much of the team doesn’t see that much of a point in spending the considerable effort to at least put in some sort of a test harness with Fitnesse tests.

I did point developer #1 in the direction of hooking Fitnesse up to the service layer which are just plain old POJOs. This should make the testing the business logic a lot easier. He really wanted to use Fitnesse to do an end to end test, but I explained that there was much more bang for the buck in hooking in below the view layer instead of trying to mimic it.

Spent some time watching a screencast by Brian Marrick on Model-View-Presenter instead of Model-View-Controller. It would appear from the screencast that views have everything possible scraped out and popped into the presenter. It uses the Observer pattern and simply fires off events when things like buttons are pressed. The view layer is very thin made up mostly of getters and setters and probably is to simple to bother testing. The presenter is listening for events and acting on them. Code you might actually want to test goes into the Presenter layer.

When I have some time I think I may need to dig into an actual example to get the idea.

Good business customers are a great resource. Today, at a Sprint review meeting, the product owner’s boss explained that she would really like another release planning exercise to determine when the team can deliver, but that she’s not holding anyone to a specific date. Then she followed up with something even better.

Well it turns out we’re going to make the second part of the system a lot simpler. We thought we needed the ability to do audits based on maybe twelve answers to a question. Turns out we’re at about 99% within standards on all our tasks and we don’t really get much out of asking detailed questions in the application. So we decided just to ask if it got done on time, or it didn’t. Just binary options. Therefore, there isn’t enough value in developing the more complex solution.

They get it, they really get it! This is one of the best payoffs you get out of Scrum, Lean, Agile. When you:

• make development transparent
• get regular feedback
• keep asking the question, “Does this provide real value?”

You can dramatically reduce waste.

I watched a Google Talk video by Rick Mugridge on using FIT and towards the end of the talk he mentioned a mythical FitLibrary2 which largely eliminated the need for writing Fixtures. I’m really not sure how this would work since he did a lot of hand waving around the issue, but apparently if you’re developing a really clean domain you shouldn’t need to use Fixtures at all unless you have to test the GUI layer or something similar. Sounds great, but I don’t think I’ll quite get it until I see some concrete examples.

Friday I got stuck on getting a build migrated from CruiseControl to Hudson. It ended up taking about two and a half hours to track down and fix, some of which got done over lunch. (Turned out to be an issue with an empty directory not being checked out from CVS and Clover not being picked up in a CLASSPATH) I remember as I was working on it I really felt like I was in the flow state. I didn’t look at my email, calendar, or phone and I really never got up from my desk to look at anything, expect to walk upstairs and pull my lunch out of the fridge. I knew the problem had to be reasonable since the ant build worked fine in CruiseControl. I kept making progress and getting more useful feedback. When I finally cleaned up the issues and picked my head up again two and a half hours had passed.

I find it fairly easy to get into flow doing development, especially nowadays when development at work is an extra treat. I can’t remember the last time I was in the same flow state doing some management work, from working on training plans to strategizing on how to collaborate with our sales force more effectively.

I don’t find myself in the zone as often with management, so I have to really work at it. My best strategy so far has been to concentrate on getting one significant task moved forward each day. Maybe Monday morning I’ll feel the flow as I concentrate on writing up all the training requests and justifications for my team this year.