For two years now we’ve been rolling out and upgrading our Java development process to follow the more important principles and practices of Agile development. When the time came to make a similar transformation in our Microsoft development, we found ourselves with some interesting choices to make.
Thatcher and St. Francis of Assisi
It should have been very straightforward:
replace “j” with “n” // or similar
}
The experience should have been analagous to the prayer of St. Francis of Assisi that Margaret Thatcher famously recited on the steps on Downing Street on her election as UK’s Prime Minister: Where there is jUnit, may we bring nUnit. Where there is ant, may we bring nAnt. Where there is Cruisecontrol, may we bring Cruisecontrol.Net. (The prayer goes on to bring hope where there is despair, two emotions that every software engineer is intimately familiar with).
Redmond, hear our prayer
But it wasn’t that simple. There was an extra factor in play that changed everything. Team Foundation Server. This new offering is Microsoft’s answer to the question “How the hell am I suppose to create enterprise systems with an agile team using VSS and VB6!?” Under one hood it combines enterprise source control, work-item tracking, centralized builds, and more. We couldn’t ignore it.
In our Java development environment we reduce the risk of vendor lock-in by abstracting ourselves and our processes away from the IDE and other tools (often through opensource tools, and noteably through Spring). In the Microsoft arena, vendor lock-in is the starting point. Deluding oneself by abstracting over your monopoly provider is a waste of energy. Or to put it in more Java-partisan terms, if you’re going to embrace the dark side you may as well use both hands. After 3 months or so in this passionate clinch, I can start to make some observations about TFS and Agile development on the Microsoft platform.
- Team Foundation Server works and it works well. Are you surprised? I was. The toolset is stable, and while it is not feature-mature, it handles very well indeed.
- Team Foundation Server is very extensible. Again, I was surprised. Microsoft is not dictating our use of their tool - they have made it openly and relatively easily extensible.
- We’ve only scratched the surface. One of our very experienced Microsoft developers has just come back from a TFS event in Dublin, and there is much more under the hood than we are presently using.
Our C# developers are writing unit tests using VisualStudio 2005, and these tests are being run as part of the Continuous Integration running on TFS. However there are more steps than necessary to get the unit tests run as part of CI and the CI itself does not come out of the box and needs to be added on as a custom extension.
We’re using TeamBuild to manage central and reproducible builds, but we have to write an amount of custom build code to manage our release builds.
In summary: So far so good. Our challenge over the coming months will be to decide how to continue to put more and more DSI direction on this powerful engine.
- brendan lawlor
Technorati Tags: Agile, nUnit, nAnt, Cruisecontrol.Net, Team Foundation Server, TFS, C#, VisualStudio 2005, TeamBuild
1 Response to “Can Microsoft development be Agile?”