October 13, 2008

...Learn TDD with Codemanship

Productive Teams Are Business Assets. Recognise Your Investment In Building Them.

So here's a joke. You may have heard it before, in which case please don't spoil it for the other readers.

Q. How many weeks does it take your average OO software development team to ramp up to the point where they're delivering tested code, visible features and have build and test automation up and running? From a standing start? Does that include implementing a Agile process from scratch with a new team of people who've never worked together before? In a new office? On a client site (so you have no control over your environment)? How long would it be before you were delivering real features to the business?

A. It depends.

My own experience has been that just to be squirting out working, tested code of a provably high design and implementation quality from a standing start is that it can take a couple of months or more.

The list of things you have to get in place for that to happen is far longer than most of us tend to acknowledge. Everything from network access to source control to build automation to stationary (those story cards don't order themselves) and whiteboards. Just getting the room in shape can be a week or three of team effort.

Then there's the approach. Contrary to what you may have been told, we don't all carry around a book called "How To Develop Software" and arrive on teams with exactly the same understanding and outlook as each other about how to go about the business of writing code. It can take a lot of work - a lot of talking and debating and compromising (if you're lucky enough to work with a team that compromises, of course) - to reach a consensus on key practices and processes that the team will work to. That can take quite some time, too - especially if you want your finished approach to actually work. (We never really had that problem with RUP. We knew we were probably going to fail. But what the heck?! The documentation was going to look superb!)

And then there's the architecture. Oh boy, is there the architecture?! How long have you got? Back in the old days when men had fancy moustaches and fought to the death over the affections of some emaciated, disease-ridden debutante (those were the days, right guys?) life was much simpler. You slapped the cad about the face with your glove, proposed pistols at dawn and proceeded to blow holes in each other before repairing for breakfast at Mrs Miggins Tea Shop. Simplicity itself.

These days we crowd around whiteboards and throw loaded patterns at each other, until one of them explodes and we end up with Mementos all over us. Then we repair to our workstations and glare at each other for the rest of the project.

Anyway, it's an horrific, costly and potentially very time-consuming process. We're lucky if, by the end of it all, we've managed to agree a single thing - like that the code should run on a computer...

Add to this a million and one little gotchas - everything from tool and framework licenses to setting up Wikis to figuring out where to get a decent cup of coffee round here.It all takes time. And that time has to come from somewhere.

To get a team to a point where they are able to deliver anything of any value, you must invest tens of thousands - maybe hundreds of thousands - of pounds. And it is an investment. A productive team is an asset that has to be built up.

If you fail to recognise the value of that asset, you will make the mistake that so many employers make, which is that productive teams aren't worth preserving. All too often I see teams being broken up and laid off after a successful delivery, when - in reality - the team itself is every bit as valuable a business asset as the software they've created. (Often moreso.)

OK. So the punchline still needs some work...

Posted 12 years, 4 months ago on October 13, 2008