Month: June 2004

For the last 9 months I’ve been working as part of the best project I’ve experienced in my career so far. The project has successfully delivered into production 5 times in the space of a year, with only 2 production bugs (each of which were fixed and deployed in less than a day). The real customers are happy due to the successful delivery (and relatively low total cost), and so are the project team due to being able to deliver successfully while keeping a sustainable pace and good team spirit throughout.

So, what’s been the secret of the team’s success? As I roll off the project, I want to write down some of the reasons before I forget.

Great People

The core team is 14 people – 1 Project Manager (PM), 2 Business Analysts, 1 tester / admin and 10 developers (including 1 developer taking an iteration manager role). Everyone on the team has been top quality. The most important attributes throughout the team have been:

– Desire for team success over personal achievement

– Knowledge and acceptance of own abilities and limits

– Willingness to speak up

– Willingness to accept the team’s decisions over personal choice

Individually, the PM is the best I’ve ever worked with. The way he has worked with the business (in areas such as expectation management) has been crucial to both the happiness of the business themselves, and the rest of the team.

Its interesting to note that even though there have been 10 developers thoughout, there has been considerable rotation of who the 10 people are. This has been possible due to the qualities above, and also because of practices like pair programming.

So lesson number 1 for a successful agile project:

Create a great team, and focus on getting an excellent project manager

Use Business Analysts as Customer Proxies

Having an on-team customer is a great idea since it means that developers can quickly get feedback for questions about how a story should be implemented, and also the customer can give early feedback for how a new feature is being developed. (Note I say ‘on-team’ rather than ‘on-site’ purposefully to show that the customer is part of the core team – a ‘pig’ rather than a ‘chicken’ in Scrum-speak.)

The problem with using a ‘real’ customer though is that ‘real’ customers also need to do ‘real’ work, and so there is a a conflict of interest between getting their ‘real’ work done and helping the team deliver the project. (This reminds me of the ‘context switching’ problems Tom DeMarco talks about in his book ‘Slack’). There’s other problems with using ‘real’ customers too, but this to me is the biggest.

So on our project we haven’t had an on-team ‘real’ customer. Instead, we have 2 Business Analysts that act as ‘customer proxies’. The BA’s need to do (at least) the following:

– Talk with the customer groups to come up with a set of features

– Figure out how these features can be coalesced into a set of stories

– Communicate effectively with the developers to explain the problem domain, and the stories to be implemented

– Work with the customers to get early feedback (e.g. from UAT)

Having the BA’s as part of our core team has allowed us to keep open and active channels of communication, enabling early and relevant feedback to issues.

Lesson number 2 then is:

Use a pair of on-team Business Analysts instead of on-site customers

These 2 areas have been about people, and team structure. I think they’re the most important lessons I’ve learned from the project. In later entries I hope to talk about areas such as how planning worked, day-to-day team practices, and development practices.

When you want to work on a web application in Visual Studio the default behaviour is to use a project that uses Frontpage server extensions. (Web applications include ASP.NET projects or Web Services.) There are big problems with this:

– Every development environment must have IIS setup, even if its used for working on part of the app separate from the web project.

– Every development environment must have IIS setup, even if an alternative ASP.NET runtime is being used (e.g. Cassini)

– Every environment must have a virtual directory set up with a common name (this is similar to the Common Absolute Paths Anti Pattern)

– Source Control Integration is often problematic

The solution to this problem is to just use plain DLL projects. You’ll need to explicitally add references to the System.Web assembly, but that’s basically it. You’ll probably want to change the Debug and Release ‘output’ paths to just ‘bin’ aswell, since that’s the default for web apps.

One restriction is that out of the box Visual Studio won’t allow you to create a new aspx/asax page and associated code behind using ‘Add new’ on the project for a DLL project. There’s a work-around, but it needs to done for every developer environment. Here’s how:

– Go into C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\CSharpProjectItems\WebProjectItems\UI and open the ui.vsdir file

– Copy the lines that end in WebForm.aspx, WebUserControl.ascx, HTMLPage.htm, Frameset.htm, StyleSheet.css, and the ‘mobile’ types if you want them too.

– Paste the lines into C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\CSharpProjectItems\LocalProjectItems\UI\ui.vsdir

– When you choose ‘Add new item’, the web templates will now appear in the ‘UI’ subfolder (you may need to restart Visual Studio first)

2 notes – if you installed Visual Studio somewhere else you’ll need to adjust the paths, and you should also backup the us.vsdir file you are changing. (Thanks to Owen Rogers for pointing out this workaround)

Some other behaviour you get for free when you do use web projects is:

– Hitting F5 launches a browser window at your default page

– You can debug the server side of your application

If you switch to using DLL projects you can still debug your ASP.NET hosted application by using one of the following alternatives

– The easiest way is to manually ‘attach’ to the ASP.NET worker process (In Visual Studio, go to ‘Tools -> Debug Processes’, and select ‘aspnet_wp.exe’). This process automatically starts the first time you access a ASP.NET resource. Doing this will mean you can debug the server-side of your application as normal.

– Alternatively, you can set the debug properties on the DLL (right click on the project, select ‘Properties’, then select ‘Debugging’ in ‘Configuration Properties’). Set ‘Enable ASP.NET Debugging’ to true, set ‘Debug Mode’ to URL, and set the ‘Start URL’ as required (there seems to be a bug in VS where you need to reopen the properties box to be able to set this last property.)

Benefits to this scheme beyond solving the original problems are:

– Since all source is developed under one tree it is much easier to work on 2 copies of the same project on one machine

– Similarly to the above point, it is much easier to work concurrently on more than one branch of the same project on one machine

– Its faster – visual studio just needs to use file access

– Its simpler – developers are already used to working with dll projects so they don’t need to learn anything new.

– You can compile, and run tests that don’t depend on retrieving web content, without having IIS running.

Some projects I’ve worked on in the past assume that certain files can always be found at an absolute path, eg ‘c:\program files\some cool library\library.dll’. Such files may be dependencies, or deployment target locations. This is a situation to be avoided!

The main reason this is so bad is that you may not actually have control over such paths when your application gets deployed. For example, many IT operations departments use ‘C:’ just for the Windows O/S, and put all other files on a secondary drive (e.g. for backup purposes). If your project assumes absolute paths, such problems may not arise until you finally reach production.

However there are other problems, like what happens when you want to work on 2 versions of the app at the same time (e.g. trunk, and branch)?

But there is good news – you don’t need to hard code absolute paths into your system! Alternatives are:

– Use relative paths. As an example, setup your source control directory structure such that you always know where your dependencies can be found relative to your project’s source code. (This may mean you save third-party binaries in source-control but this is not a sin!)

– Use deploy-time configuration. Get your build environment to generate environment-specific distribution files where parameterised paths are expanded to absolute paths at the last moment.

– Use environment variables, like path. This is a ‘last-chance’ option since it is system-wide, rather than application-wide in scope, but stops you having to hard code paths in your application at least.

To check that a project I’m working on isn’t using absolute paths, I tend to do one of the following things

– Have 2 copies of the development tree checked out on my machine. Switch between them occasionally and check nothing breaks.

– Have my continuous integration and ‘development test’ environments specifically use different paths to that of the development team.

A couple of weeks ago I was at XP 2004. Due to my goldfish-like memory I’ve already started forgetting what happened, but here’s some things I do remember:

• It was good to meet new people, like Angela Martin, Rick Mugridge, Charlie Poole and the Exoftware folk
• It was good to catch up with people I’ve met before like Josh Kerievsky and hang out with my fellow Fowlbots Chris Stevenson, Chris Matts, Ivan Moore, Martin Fowler, Owen Rogers and Steve Freeman
• Hot Topic number 1 – the customer role (including a great panel.) Chris Matts has blogged a tonne about this so go read it!
• Hot Topic number 2 – acceptance tests. There’s a still a huge amount of debate about what an acceptance test is, and how to implement them (e.g. Fit is not a panacea).
• Talked with Charlie (NUnit) and Owen (fellow CruiseControl.NET project lead) and others about .NET tools. We’re going to work more on Mono compatibility if we get some time
• I presented my paper on Enterprise Continuous Integration. The demo I gave is available here, the paper is available here.