April 23, 2005

...Learn TDD with Codemanship

Test-driven Development & Off-shoring

A lot more software development is being outsourced to developing nations these days. I can quite understand why managers might feel that, with much lower costs for off-shore developers, this is an attractive option. But there can be a nasty sting in the tail with off-shoring.

It's long been understood that a high level of rich interaction is needed between the customer and the developers to give projects a chance of success, and having your customer in London and your developers in Mumbai is a major barrier to achieving this.

Again, the myth that there is a clear distinction between specification (using, say, use cases and UML diagrams) and programming - with the former being design and the latter being construction - can give customers unrealistic expectations about how off-shoring can work.

Certainly, if you're going to have development done overseas, you need to provide very clear specifications. Unfortunately, the usual routes are too ambiguous. Even detailed UML models will have gaps and inconsistencies that will require clarification. Of course, you could go to the expense of creating formal, validated specifications (eg, using UML and OCL and associated highbrow tools), but then you're getting into the territory of almost, nearly writing the code itself. The savings you might make from off-shoring can easily be outweighed by the extra investment in analysis and design needed to create specifications watertight enough to make the whole process work.

A much simpler approach might be to have a small team of very strong developers based on site with the customer, and have them write executable tests (UAT scripts for system-level and unit tests for component-level) which they can drip-feed them to the off-shore developers in an agile, iterative manner. The benefit of this approach is that executable tests are unambiguous (if you write them effectively), so the developers know exactly what's required, and - unlike with formal specifications - you can actually run the tests when the code is delivered and get an immediate and definitive answer to whether the right thing was delivered - assuming you wrote the right tests, of course...

If you couple this approach with new technology for remote collaboration (eg, Windows Messenger, GoToMyPC etc), the local developers can even pair program with the off-shore developers to help move the whole process forward more rapidly.

It's still not as good as having everybody co-located, but it's a massive improvement on the "throw a spec over the wall" approach that has burned many businesses in recent years.
Posted 15 years, 9 months ago on April 23, 2005