I’ve been at several organizations, both large and small, who keep the same chant over and over that offshoring is the key to getting your software cheap. When it comes up, it never seems to be to be a good solution, and so far that’s panned out. None of the offshored projects have succeeded. That’s right – none. They’ve either been cancelled, or completed but then thrown away. Generally any code is rewritten before we fix it in house.
From time to time on the TDD and XP mailing lists, questions come up about doing TDD/XP with offshore teams. While there are elements of XP that can be done – including TDD if the team is aware of it – one is lucky to find teams who do that. And usually goes against the low bid. Why? Well, Brad Wilson on the TDD list captured exactly what I’ve always thought, but didn’t put into the right words:
Let’s be honest here. If you’re off-shoring, the implication is that cost is more important than quality. You will spend a lot (in terms of man hours) trying to re-inject quality into the process. I think you are fighting the wrong battle, personally.
In other words, if you want something done fast and cheap, offshoring is probably right for you. If you want a quality product you are going to have to pay for it, whether that be a local team or remote. Fast, Cheap, Good – Pick 2. We’ve all heard it, but seem to want to throw it out when it comes to offshoring.
To be fair, I don’t think it is the fault of the offshore developers. Sure, I’ve seen offshore devs who claim to be experts in everything, but need help writing a simple C# class. But the bigger problem almost always comes to communication – you can’t predict what you want upfront, but they are going to build exactly what you tell them to build. Without an ongoing relationship where developers and customers can understand one another to build what they need, it’s almost always going to be not as good.
In /Lean Software Development/ Mary and Tom capture this idea perfectly. They discuss Toyota, and how the Die engineers are expected to know a lot about what should go into the door panel, and stay in constant communication with the leads so they can make changes as they go. This also means they have to delay decisions until the last responsible moment. Without that relationship between knowledge of the product and communication with the leads to understand the customer demands, the die engineers couldn’t be nearly as effective. Neither can the software engineer who is handed a spec and expected to build it in isolation.
So, quality and speed are possible in a software project. But to acheive it, you have to be willing to spend the time and money on the communication and relationships necessary for those building the software to understand your project – and you.
“… delay decisions until the last responsible moment.” I live by these words but so often I find myself repeating the mantra to those around me who think they believe but obviously don’t. This is right alongside “don’t write code you don’t need.”
Great comment Sean. I think it’s sometimes hard for people to do. Basing design decisions on the faith that when it /really/ comes time to make them we’ll have more information, be smarter, better, faster, etc just seems to be difficult for some people.
If you have a very tight specification it can make sense to have it delivered offshore. However, it is very difficult to have a tight specification for a larger project in advance.
For offshoring to work, you need to develop the relationship by giving the offshore team a series of small stages to do (each with a detailed specification), rather than one large project.
As your users see more of your project, they can make changes in subsequent stages. The offshore team will learn more about your business (and hence not require quite as detailed specifications in future), and you will learn more about the offshore team and their skills and be able to plan accordingly.