Simon is a hands-on software architect who works within 
[Twitter] simonbrown: @kpseal that might explain why my full 99GB backup took just a few hours!
[Coding the Architecture] I did some technical consulting/due diligence on a large software development project recently where I'd been called in to look at how the project team was dealing with some of the non-functional requirements. I'm not sure exactly how large ...
When will the offshore bubble burst?
When will the model change from distributed waterfall to one that is collaborative and iterative?
Hearing management teams talk about offshore is becoming a more frequent occurrence these days and most large organisations that I've met in the past six months are starting to invest in offshoring if they've not done so already. That's not really surprising when you take a holistic view of the economics, but I'm convinced that the current offshore bubble will burst in the next 1-2 years, making way for a much more collaborative model. Let me explain.
Most organisations see offshoring as a way to reduce the costs associated with software development. The basic premise is that "software development is a commodity" and that "commodity development is low risk and can be easily offshored". Effectively, organisations are taking a "software factory" approach to software development where they throw specifications/contracts at offshore teams and expect working software in return. There are a couple of points that I want to pick up on here.
- Software development is a commodity : I've heard this a lot recently, from organisations on the buy-side and the sell-side (e.g. consulting companies and system integrators), but I don't agree with it. Software development is still a complex discipline and you can see this by taking a look at the rate of technology change driven by people trying to make development easier. Just look at how many Java web application frameworks are available. Sure, there are parts of software that can be and have been commoditised, but there's still a lot of bespoke development that goes around it.
- Offshore reduces costs : The most compelling reason for organisations looking to adopt offshore is that "the daily rates are much lower for offshore resources than onshore resources" and if you compare them in terms of cold hard cash, you can't argue with it. However, I don't think that organisations are thinking about the additional investments that they need to make in order to give the current offshore model a chance of success.
For example, it's fairly safe to say that most organisations work in a fairly ad hoc manner and need to put some investment into improving their processes to enable offshore development to work. This might include improving the way in which requirements are captured, prioritised and documented before even thinking about how best to structure the overall solution and define the work packages/specifications that will be sent offshore. Plus, you then have to factor in the additional cost of testing that will undoubtedly take place when the end-product has been developed and the potential latencies that will be introduced from teams being distributed across the globe. Sending work offshore introduces work onshore to manage it.
If you're reading between the lines, you might be thinking that I think offshoring is a bad idea, but that's not the case. The same problems apply regardless of where the "external" team is based because you've artificially introduced barriers that prevent the teams from successfully working together. Offshoring just makes it harder because of differences between time zones, cultures, etc. What you have here is a distributed waterfall model of software development.
- Requirements : The buy-side organisation figures out what they want, scopes it and defines it.
- Analysis : The buy-side organisation analyses the problem and starts designing a high-level solution. Anything from a small component to the full solution is documented in enough detail so that an external team can understand and deliver the solution. I've even heard of teams that take this process down to the pseudocode level!
- Design : The offshore team take the analysis and start designing software.
- Implementation : The offshore team implement and unit test their code.
- Test : Depending on what they are developing (i.e. a component or a whole system), the offshore team performs some higher level testing before shipping the deliverables back to the buy-side for further system and integration testing. The usual quality assurance/bug fix cycles commence, with enhancements and change requests being sent offshore.
Our experience in software development has proved that the waterfall model doesn't work in many cases, for a number of reasons. These range from not delivering a fit for purpose solution because the requirements change once the design is "signed off" to actually failing to deliver at all. Plus, from an architecture perspective, handing-off your architecture to the development team also reduces your chance of a successful project. I've been called in to look at a lot of poorly performing, unscalable, etc solutions recently where the architecture hasn't been thought out well enough. The software factory approach to software development needs well defined signed-off specifications for it to work, but that's the one aspect of software development that we know just isn't possible (in the commercial world, anyway). If organisations can't get software development right using this process with an onshore team, how are they going to get that same process to work with an offshore team? Offshoring has the ability to reduce costs, but you're making some trade-offs.
No, the real problem here isn't offshoring, it's the engagement model that organisations are using. I think that, for offshoring to work, the engagement model needs to move away from the distributed waterfall and towards something that is more inclusive, collaborative and iterative. Agile methods bring everybody together and focus their efforts towards a common goal, which is the same thing that needs to happen with offshoring. Offshore teams need to be fully brought in to the overall software project that they are helping to build and the focus needs to switch from seeing them as a service provider to seeing them as a part of the team. More involvement and more collaboration is what I think will help make offshoring a successful approach. In fact, let's not even use the term "offshoring", let's just think about this as a distributed project team.
To wrap-up; I don't think that the current "software factory" approach being adopted by most organisations is healthy or sustainable, and organisations are starting to become dissatisfied with the results they are getting. Waterfall approaches have failed in the past, what's different this time?
