I remember searching hard for good technical podcasts about a year ago. There were really just a few at that point like Drunk and Retired, ZDot, and the Polymorphic Podcast. Today there’s a wealth of them. Just following a blog link I noticed NetObjectives has a Lean Agile Straight Talk podcast.
All this means is I have about 48 hours of backlog right on the old iPod and I can afford to be picky. A lot of podcasts I would have listened to on IT Conversations now don’t even warrant a download.
About 9 months ago I tried to explain to one of my developers the idea of an iteration zero. Sort of a quick organization of setting up for the project for a few weeks. I tried to find some references to it to point him too, but I didn’t manage to find any even though I was convinced I read about it somewhere.
If Scott Ambler is right it’s an assumed idea for Agilists, but “little has been written about this subject.” His definition is:
Agilists refer to the initial iteration of a project as “Cycle 0,” during which you determine whether the project is feasible, setup the technical environment, start building the team, and do sufficient modeling to support these activities. Sounds like what you do on a traditional project? Absolutely. The difference, however, is agilists achieve the same goals with a lot less effort—Cycle 0 is typically a week or two at most.
Small anecdotal evidence, but out of our three official Agile pilots the one that went the smoothest had a good 3-4 weeks in Cycle 0. The other two leaped off on Sprint #1 with minimal planning. The biggest pain seemed to be that very little initial work had gone into requirements, use cases in our world. For Sprint #1 it was hard for the developers and QA folks to do estimates and it’s taken a while to catch up.
James Shore has a post on Informative Workspaces. He suggests using hand drawn charts and having everyone on the team update them where possible. Some of his ideas for charts include:
- A chart showing pairing time.
- A chart showing pairing combinations.
- A team calendar.
- A code coverage chart.
- A chart of tests executed per second.
- A chart of the lines of code in the system.
- A chart of the age of the oldest open support request.
- A chart of non-story work.
- A chart of unavailable customer guesses.
- A chart of customer and programer interactions.
We have yet to do any serious experimentation with pairing yet, so we haven’t used charts for that. We have used charts for the team calendar and code coverage. We’ve also used charts for number of unit tests and to track tasks. Reading this post gave me the idea that I need to try doing a hand-drawn chart of our code coverage. I tend to use a stock Clover print-out and I only occassionally change it. I really like the idea of the team owning the chart and updating as well. This does happen with the calendar and the task board, but I think it could be useful for some of these other charts.
- The Struts project has gotten confused with the split between Struts Shale and Struts Action (Webwork) which has hurt adoption.
- “JSF continues to be the most over-hyped under-used framework in Javaland.”
- He’s yet to “meet an unhappy WebWork fan.”
- The learning curve on Tapestry is too high and it doesn’t maintain backwards compatibility.
- Spring MVC is fine, but Matt has found “WebWork much more pleasurable to work with.”
- Given the options you should go with Struts Action 2 (aka Webwork).
I’d be happy if WebWorks became the defacto web Java web framework as a successor to Struts, but unfortunately for now it’s still a wait and see game. In the meantime after about 9 months with JSF we continue to struggle with the six phase lifecycle and reliance on tooling. At least Ruby on Rails has forced the java community to wake up and smell the coffee.
Continuous Integration is a good thing.
Hmmm, it works on my machine.
I paired up with a developer yesterday to hook a new project into the build box and Cruisecontrol. We expected a few wrinkles since this is the first project we’re hooking up to maven instead of ant. Should be just a simple **
We got past the parameter settings faster than expected, maybe 5 minutes on syntax errors like using
and forgetting to checkout the project manually for the first run. So after five minutes it’s up and running, but it starts failing soon after getting started.
So next we try debugging by just running the maven goals in the checked out codebase. Over and over again it pulls down about 10 dependent jars and then bails on the 11th. It’s not the same jar each time so the error isn’t obvious. Current theory is maybe the build box is being throttled by the proxy server, but it was late so we’ll get back to it in the morning. The build of course works on the developers machines.
Without hooking up the continuos integration early in the project we would have missed what may be a fairly subtle bug.