As noted previously, I spent all of last week at the Better Software Conference. I was speaking on Thursday, but prior to that, I had the opportunity to attend a variety of technical discussions and workshops. Here is my coverage of the third day. I've covered the first and second already.
Wednesday was the official first day of the conference and kicked off with everyone together for the welcome and some keynotes. I couldn't tell you for sure how many people were there, but it seemed pretty full from where I was sitting.
The first keynote was from Norm Kerth who was one of the pioneers of “retrospectives”. For those of you still trapped in the large corporate world or the waterfall world, these have previously been called “post mortems” and are usually blame games. The intent of a retrospective is to assess the project without the blame. Norm went through the reasoning for retrospectives, what the core principles are, what can be gained from doing them, and discussed numerous organizations who did them. I was surprised to see my alma mater – Rose-Hulman on the list. Then I remembered that I used to work with the group called “Institutional Research and Assessment” and it all made sense. Rose – along with many other organizations he mentioned – uses retrospectives to regularly evaluate their efforts and adapt to new information, methods, and situations that arise.
The second keynote was from Michael Mah who spoke on “Agile Productivity Metrics”. The entire premise of his presentation was that individual anecdotes are great, but cold hard numbers are even better. Using the estimated project size and the industry, you could project the amount of time, effort, bugs, etc. within the project by comparing against their database of 7k+ projects of varying sizes, industries, and team compositions. While I find that whole concept a bit suspect, he also used the data from a pair of complete projects to compare against industry averages to determine some simple metrics. In addition, he showed how using your team data, you could measure progress over time, etc. It was pretty fascinating but was highly dependent on historical data… which few teams would have. Michael has a blog in case you're interested in learning more.
Next was Bob Galen's presentation on There's Always Time for Pragmatic Project Planning. I was recently one of the commenters and reviewers of his upcoming book for the Pragmatic Programmers (entitled Pragmatic Project Estimation, IIRC), so it was good to finally meet him. Bob covered all of the kickoff activities normally associated with a project… chartering, planning, a bit of estimating, etc. His content was great, and he went into quite a bit of depth discussing the value and need of these aspects. Unfortunately, from what I've seen, the initial chartering is the easiest part and the estimation is where things break down. I'm looking foward to his book to fill in some of these gaps. Who knows, you might get one of the first reviews here.
At lunch I sat at a random table – my normal practice at conferences – and happened to sit down with Dave Mount from jSoup who was about to present on Web Services Interface Design: Pitfalls and Proven Techniques. This was one of the most technical presentations of the conference and I have to admit that it was a great change. Dave was heavily involved in architecting and implementing a set of web services and had some great tips and tactics to make things easier and more robust. One of his most important points was putting the logic in the right places. Many developers tend to push things out to the end points (aka the UI) and when a new UI is implemented (aka a WebService), you end up with problems concerning security, validation, and a whole host of other factors. Good call Dave.
My final presentation of the day was Michael Portwood's Leadership—The Forgotten Element of Agile Development. As soon as I saw his outline, I knew I was in trouble. About half of his points directly correlated to points in my presentation. On one hand, I was happy that others are seeing some of the same issues and have similar tactics in dealing with them. On the other hand, he had phrased a few things much better than I had. Time to make updates. Other than that, he laid out some scenarios and tactics for making the distinction between leadership and management and then practicing leadership. One of the most important points – more implied than said – was that the concept of leadership is distributed among the entire team instead of concentrated in a few roles. Obviously this completely shifts the dynamics.
Unfortunately, I skipped the Linda Rising's keynote entitled Patterns, Influence Strategies, and Stone Age Legacies in order to take a customer call.
After the keynote, the reception began. I spoke with a few people who's names and titles I had heard mentioned elsewhere, but it began to get interesting once I went to the open bar. I was standing in line and started discussing Portwood's presentation with the person in front of me. We disagreed on a few points (like the implied one above) and started hashing out a few things. After a bit more discussion about testing and tactics, I mentioned the testing setup of one of my customers and then mentioned Mike Clark's book Pragmatic Project Automation which I used to completely rebuild a project last year. Then he told me who he was… Jeffrey Fredrick!
Yeah, I wasn't sure who he was at first either. Then he mentioned his real claim to fame… his company is the one using lava lamps to describe build status. Now that clicked. Oh yeah, he's a contributor to Cruise Control too, but how does that compare to lava lamps?
We continued to talk for quite a while and discussed build and testing methods – he was mostly making the contributions, I was absorbing. But then we started discussing his company's difficulty in selling groups of Continuous Integration. It sounds like a horribly difficult sale. Most organizations don't seem to see the value of testing – unit or otherwise – until they're already in the pains of the process. But then, in order to buy the services, they want to see how other groups have used it successfully. Yes, the classic Crossing the Chasm dilemma.
In summary, this first day was pretty good. Luckily, I haven't joined any bad presentations and I have gotten a great deal of notes, practices, and contacts which I hope to exercise. Tomorrow I'll cover the rest of the conference, my presentation, and some closing notes.