Developing software in the global village
Have things really changed in the past few decades?
Reg Reader Workshop Anyone would think the kids of today had invented globalization.
All this talk of largely text-based communications mechanisms used in social networking and blogging gives the impression that the mechanisms we relied upon in the earlier days of computing – bulletin boards, Usenet News and so on – were in some way different.
Similarly, one could argue that software development activities are no more distributed than they were a decade or two ago – the larger multinationals and systems integrators have long been using the most appropriate resources for the job wherever they happened to be, bringing in third parties and subcontractors as needed.
This picture may be rose-tinted, but nostalgia aside, there has for many years been such a thing as a geographically-dispersed development team, drawing on a variety of resources.
So, what gives – are things really any different today? There’s a few factors that may have had an impact, notably how the twin topics of outsourcing and offshoring have affected software development organizations. As we’ve emerged coughing and spluttering from the outsourcing wave only to have the offshore wave crash on our heads, the only thing clear is the ever-broadening number of options, for organizations large and small.
When we did some research into outsourcing in particular a few months ago, what became clear was that not all development activities were suitable candidates. It stands to reason that organizations should want to keep the more strategic activities in house and outsource the more tactical stuff. What’s fascinating is how this view on outsourcing depends significantly on whether IT is viewed as a source of business advantage, or as a cost centre – we can see this from the chart below. And similar research tells us that the picture is the same for local vs off-shore project resourcing.
But isn’t this counter-intuitive? Surely, goes the common wisdom, the purpose of outsourcing or offshoring is to take costs out of the system? This may have been the case a few years ago, but today we’re seeing plenty of counter-examples – use of specialist organizations that happen to be based in specific locations for example, or geographically distributed teams in order to reap the time zone benefits, all are reasons why to take advantage of outsourced resources.
But the road to hell is paved with failed outsourcing or offshoring examples. From a software development perspective there are all kinds of things that can go wrong - not just contractual issues. The route is rife with process failures and communications breakdowns. When it comes to offshoring we know of organizations that have had great experiences and those who haven't – and we suspect that this is as much down to the checks and balances in place as any inherent difficulties with the distributed model. “Never again,” said one project manager to me earlier this year. “You just can’t get the quality.” “Absolutely not true,” said another. “It’s all down to recruitment.” Are they both right, or was one just luckier than the other?
So what do you reckon? Is it possible to get the perfect balance of resources, be they off- or on-shore, in-house or external, and get the whole lot working better than a bunch of people in a room? Where are the real benefits to be had, and what are the absolute no-nos? Is it really just a case of applying the age-old principles of best practice, whatever the situation? Have you any classic examples, or indeed horror stories to share? Let us know – we’ll feed them into the Reg research machine and see what picture emerges. ®
Own off-shoring experience
Having worked for a financial company that was one of the first to out-shore s/w development (and still does) my experience is not good. I personally met the following problems
Software (open-source and other) simply taken without any licensing costs or attribution made. (We found this out by having the sources brought over to us and physically checking them);
Healthcare data (patients information) being present in a financial system even after we insisted that it must be possible to build the database from scratch;
Extra (substantial) licensing costs after parts of the product were insufficiently licensed and in order to carry on legally using the product we paid to develop we had to pay extra licensing costs;
Our project management team at the off-shore secretly doing a deal to have the project done by another partner (who had a relationship with a competitor of ours);
All the business and technical expertise related to the back-office product being "moved" to the off-shore. Now because of movement off-shore (no developers there want to work with AS/400 after three months) the expertise is very hard to come by. The developers here have all left.
And yet the organisation still carries on. The hourly rate is lower. The extra management and risks are simply ignored. We had tried to cover the risks in the contracts but this had no effect. Contracts were simply ignored.
What james said...
but maybe with a bit less pessimism. Yes, there is a loss of informal communications, and of developers with the deeper knowledge of the "widget" business that comes from being part of the "widget" industry and not the software consulting industry. But that doesn't mean you need NASA levels of specifications to get the job done. You just need a tighter definition of good enough and to evaluate it job by job. Developing a generic tool to be shared between widely different groups of users is going to require good specifications and process management anyhow. So it's less of a leap to go offshore. Trying to respond to UI changes in a rapidly changing departmental application, less so.
After 2 years of excuses, laziness, constant turnover (complete waste of training time when the guy/girl buggers off and leaves you with a new muppet), terrible or copied-from-google code, neverending bugs, headaches, baffling phonecalls where no-one understood each other, emails that promised to "do the needful" but went ignored, applications that just didn't work, MILLIONS of dollars, and much much more....... we had enough, and told the Indian coding behemoth we'd had enough and brought our dev team back in house.
Saying that things go more smoothly is a massive understatement. Don't know why we bothered. Oh yes, some spreadsheet said it would be cheaper.