It's now been ten years since I finished my PhD, in automated refactoring. At the time I started it, the Smalltalk refactoring browser was being worked on. It looked interesting but I needing to do something different because PhDs have to be original. I'm happy with what I chose to do - it got me my PhD.
BTW - unlike some stories I've heard from other PhonyDoctors, my supervisors were all great (I had four official supervisors in the three years of my PhD - they kept leaving to work in industry - and one unofficial supervisor. They were: Mario Wolczko, Trevor Hopkins, Jon Taylor, Tim Clement and Chris Kirkham).
I've learnt a lot since my PhD. I've now seen more evidence that the first few sentences of my thesis introduction weren't too far wrong:
The software development process is iterative, whether it is planned that way or not. The optimal design of a system depends on its current requirements. As requirements inevitably change, a system will evolve, requiring restructuring if it is to remain well designed.
I'm disappointed that there hasn't been more work in the area. Some people really didn't like what I did, but others did, which I think means it must have been an interesting idea!
I attended CITCON this weekend - it was great! Jeffrey Fredrick and Paul Julius ran this free-to-attend open space conference through their "Open Information Foundation". If you are interested in continuous integration and testing then this is the conference to go to.
Amongst other things, the conference really inspired me to think that there are lots of possibilities for continuous integration that no-one has yet tried. Mike Cannon-Brookes of Atlassian has some really interesting ideas that are being worked on for bamboo.
Recently, I've replaced CruiseControl with build-o-matic at my client, because CruiseControl was turning out to be difficult to configure and run reliably, taking a lot of effort and not giving great feedback. I wrote build-o-matic with my colleagues initially just for simplicity - but it is turning out to work better for us than CruiseControl, as well as being simpler.
For one thing, as soon as it detects updates, it shows you the change sets before it starts running the build rather than waiting until it's finished - so you know what it's working on. Also, it shows the tail of the build output in it's web page so you can see what it's doing - one of the problems we had been having with CruiseControl was telling what it was doing.
The feature in build-o-matic that has probably had the biggest benefit for the least effort has been putting images of the people who have committed changes on the web page, by scraping names out of commit messages.
I feel bad about criticising CruiseControl, because I've been using it for many years and it was the first CI server - a really great idea for a tool. Unfortunately, it does have some problems, and build-o-matic solves the ones that were most important to me.
One of the features of a CI server that I'd really like would be for it to automatically find out what broke the build. When working in a large team with people checking in frequently, you can end up with multiple commits while the build is running, so on the next run of the build, if the build breaks it can be difficult to tell what caused the breakage. Today I've implemented the first version of an enhancement to build-o-matic - currently called "blame-o-matic.py" in the CVS repository for build-o-matic and not in a release yet. It runs (for subversion only) the build for all revisions of the repository between the current revision (svnversion) and a given revision. There are cleverer strategies than just running on every revision - e.g. binary search - to find what commit broke the build. I'm hoping to implement this some time soon ... watch this space.
TeamCity is a really interesting alternative approach - I haven't tried it yet but I've heard a few people say good things about it.