The speed at which a rewrite project goes is often a very big factor in deciding whether or not it will be successful, and it’s often one of the most overlooked elements of a rewrite project.

Speed influences so many factors of a rewrite project it’s difficult to list them all in one article so for now we’ll approach them one at a time. In this post I’m going to look at the speed at which a rewrite might adopt new tools into their overall build process, but the same core message applies to almost every aspect of a rewrite, and I’m hoping that the title of this post indicates what I’m trying to get to…

Developers on a rewrite project should do it slowly.

We’ve recently introduced TeamCity into our build process (for more information on TeamCity and some further authors who’s blogs you should read please see the end of this post) and in order to get the “buy-in” of our development team we introduced the tool very slowly, piece by piece. Getting the “buy-in” (the interest of other developers and the acceptance of the changes before they have happened; giving the idea their support) of any developer involved on a rewrite project is of paramount importance and should not be overlooked. Any developer who does not support a change, or even the rewrite itself, can quickly become a problem and their concerns should be addressed quickly. Of course, the developers with the real power in a rewrite are those who know the old system inside-out so their buy-in is crucial. Anyhow, back onto our TeamCity introduction.

So, we had a problem within the development process in that it was becoming difficult and time consuming to get all the check-ins done and the latest builds tested etc. Initially we looked at what sort of tools might we might be able to use to automate our build process, something that would run on a remote machine and just build our projects and enable us to test our dependancies and gauge our platform requirements.

A small group of developers tested various tools and we eventually decided on TeamCity. Of all the CI tools available we chose TeamCity because:

a) it was free
b) it was very easy to setup
c) there was a plugin to integrate it into our CVS app – SourceGear Vault
d) we could easily bolt on tests and checks post-build

Had the Magpie effect taken hold then we may have well had it installed, running all our builds and doing a large amount of testing in one day (it was that easy to setup) but that amount of change in such a quick timeframe, to a team who are already working within a rewrite project, is just too much to adjust to. Even the best, most agile team is going to struggle to adapt to that level of structure and process change overnight. So our first, and still current, integration level for TeamCity is one build configuration per project and no tests or post-build work other than storing artifacts.

That’s not to say it won’t change – in fact we’re putting together some test plans and post-build tasks at the moment – but we’re not in a rush to make those changes and we’ll introduce those tests one at a time, over a period of time that allows us to learn and react to the changes they themselves cause.

Very recently, at our local NxtGen User Group meeting (other .net based development groups are available), we had the knowledgeful Paul Stack present to us his thoughts on Continuous Integration. At the end of his presentation he recommended a few books for those interested in CI, of which one was “Continuous Integration in .NET”, by Marcin Kawalerowicz and Craig Berntson. In the book the authors recommend that the first step should be a daily build of your project. I disagree. For one, it’s called Continuous Integration and only doing a daily build isn’t as continuous as it should be. Secondly, you’ve already plumbed the CI tool into your CSV app of choice, so why not just base your build on a check-in trigger! There’s nothing more continuous than doing a build on every check-in – and believe me, your developers will begin to love the immediate feedback they get on their changes. Doing a daily build can sometimes result in a day starting with fixing a failing build, and Mondays are bad enough already.

Its only by introducing changes slowly that you’ll get the support of the developers in your team. The worst thing you can do in a rewrite project is rush into a decision on any element of the project. Its much better to discuss any changes, ideas or proposals with your team and then introduce them into the process slowly. That way, it’s easier to rollback if they don’t work out.

Further TeamCity points of interest:

Paul Stack – Adventures of Wannabe Geek
JetBrains: TeamCity blog
Ben Hall’s Blog (Filtered for TeamCity posts)
Dennis Plucinik – Web Design Blog

The book – available on Amazon: Continuous Integration in .NET