CallContext

I have been thinking about why managers (or those who are in charge of projects - whatever they may be called) have such trouble with the concept of the "extra" work involved in test driven development, and I think I've figured it out. There's a disparity between what the client perceives as delivered software and what the software vendor perceives as delivered software. [*]

The project manager's idea of a completed deliverable is when the bits go out to the client. When they're "thrown over the wall" in nerd terms. The client considers the software to be delivered when it is performing how they expected and they can make actual production use of it. In my experience, using my hazy memory and therefor entirely pin-point accurate assessment, this can differ by a factor of say 100%!

What are you talking about?

Lets take a (contrived example of a) two month project to produce feature X for company Y:

Here's how a project team perceives the project:

Typically, there's a little bit of documentation up front to help relate the client's problem to the developers. Then they go to work bashing the bits into shape. The development phase is where the project managers/company owners perceive the work to be done, ergo where the resources are really being expended. The last bit, I called conf - for confirmation - is where the developers (typically) or the project management (sometimes), or QA (ha - yeah, right...) confirm that the product the developers have produced meets the specification that they decided on in the first place.

One month gone. We think it's right, so we can deliver it to the client and wait till they pay us.

Here's how the client perceives the project:

The client gets our delivery and then starts testing. They find things that aren't exactly what they wanted or they weren't able to correctly communicate what it was they wanted, or flat out don't work, so the bits go back and get reworked, but this falls outside of original window for the developers and becomes, essentially, maintenance. They've moved on to the next project, because what manager in their right mind is going to let a team of developers sit around doing nothing while a client makes up their minds, right?

Anyway, after a period of time, the client finally has what they think they originally asked for and they put it into production. They now consider the project delivered. One month after the development team did. So the disparity looks like this:

See, the development team thinks they've finished a month ahead of when they actually did. The client thinks that their project is a month late and wasn't delivered how they expected.

This leaves you with the following realisations:

• You under-estimated (and as a result under-charged) the project, cutting yourself out of what you should've rightly earned for the work you wound up doing in the end;
• The client is annoyed because their belief that all software projects run over time and over budget has just been confirmed yet again;
• Your team grows to hate the "project that never ends" because they're still "maintaining" it a month after they "delivered" it;
• The client thinks your company is hopeless because you didn't deliver what they wanted in the first place.

Sound familiar?

So what's the answer, clever clogs?

Well, I[*], think the answer is agile development methods. These days, it seems everyone is able to shoe-horn their particular development (non-)methodology into the agile world through some gross distortion of reality and kid themselves they're on the right path. On the flip-side, there is a growing adoption of portions of agile methods that are leading to gains for teams. Isn't it funny, you never hear of anyone's project failing because they adopted an agile methodology.

If you take the common pain points that result from any normal development approach, they are all solved by different aspects of the normal set of agile methods:

• The client is involved the whole way through the project, so they never feel like they're going to get something they didn't want at the end of it;
• The client and the team sits down and discuses the first milestone together, nutting out all the user stories up-front, and giving an estimate closer to reality because it's easier to estimate a user story than an entire project;
• Test driven development ensures the code is correct from the start, eliminating rework later on and helping you walk your fire towards the target;
• The client's continual involvement means that any course corrections due to bad assumptions or miscommunication are miniscule and rapid;
• The client gets their hands on some sort of working code earlier, allowing them to better get a feel for progress and the resulting application;
• When the user stories are done, the client will have what they wanted without the rework, and the project will truly be delivered.

It most likely will still take two months (as per the contrived example above), but it might take a little less due to less bug hunting throughout the development. The difference is the client will now be expecting it to take two months, as will you, and you will have charged the client for two months thereby actually getting paid for all the work you did, and the client will be happy because you brought the project in on-time and at the budgeted amount.

Now the disparity is gone:

The world is a wonderful place, cats and dogs live together, VB.NET programmers and C# programmers respect each other, Bill Gates apologises for Microsoft Bob...

[*] Please note that this is based on my personal experience, and may not actually represent the frame of mind of every project manager out there, or even be remotely correct...