jBlog

Monday was the first day of the QCon conference in San Francisco. I spent the day in two separate tutorials. The morning tutorial was ‘Doing TDD as if you meant it’ which was taught by Joshua Kerievsky of Industrial Logic. The afternoon tutorial was supposed to be ‘Cloud Computing’ with Stuart Charlton, however he was unable to make it due to medical reason, so it turned out to be a question and answer session on all things Agile and XP with Joshua Kerievsky.

Joshua spoke a lot on the agile process and what it takes to design software which is reliable, release frequently and most importantly constantly adds value to your “customer” with almost every release (I put “customer” in quotes because some people think that they may not have customers because their software isn’t being sold. However, that’s not what defines the customer, the end user of your software is your user). The way that they do this is decide after a release what customer requests they are going to release that week and when they’ll be able to release them that week. This can lead to release your software to production more than once some weeks and none some weeks. This can certainly have positive side effects, especially in your release process.

If your team releases using a manual or only semi-automated process, most likely frequent releases are not a luxury for you. My team at DRW has yet to master a fully automated release process, but it is a vision that we are working towards with every release. There are many tools that can be used to do this (and frankly I only know of the ones that we’ve used at some point in time). Which tool you use doesn’t matter, what matters is that you put the effort into an automated release.

The last major thing regarding frequent releases that Joshua mentioned during his tutorials was what their ultimate vision. The ultimate vision for Industrial Logic, and probably for many followers of agile, is a continuous release. Ideally they would like that have the setup that whenever someone committed to their repository, the continuous incremental build would run and then if successful a release would automatically occur. While this would involve many more infrastructure changes than just an automated release it may be a thing to consider. I have not yet given it much thought, since it was a concept I began thinking about roughly 24 hours ago, but I can see where there might be advantages to it.

All in all, I enjoyed my tutorials with Joshua and thank him for imparting his knowledge on me and the rest of us here at QCon – San Francisco 2009. I look forward to the rest of the week here and if anyone has good comments to add on this, please let me know what you think.