Developing software in the global village 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. …
Why do companies outsource? simply because they can.
In the "bad old days" there were no software houses, who would take your requirements and mangle them into something that bore no resemblance to what you wanted, needed a computer the size of the planet to run and was delivered - full of bugs - 18 months late. All these good things had to be produced in-house. Therefore any commercial enterprise of any size (J Lyons, anybody?) had to have an IT department churning out the software to keep the biz. running.
Later, when COTS software arrived, the IT dept. became customisers, tweakers and responsible for keeping the whole mess of incompatibilities more-or-less running. Later still, they became the people who pressed the button that took the backup, told the users to reboot their PCs and tried their hardest not to screw up the LAN - well, not too much anyway.
For all these changes, the one thing that has remained the same is the core business. Whether it's being a supermarket, a plumber, a bank or whatever - this is what makes the money that payes everyones' wages - not the IT element of the organisation. So when the opportunity presents itself to get shot of the whole kit 'n' kaboodle you shouldn't be surprised when the board of directors breathes a sigh of relief and signs a very large cheque.
So far as the perfect balance of resources goes, it's the same as always: let the people who do it best get on with it. In the IT world that means the specialist companies who provide the software, the design skills and the business analysis to tell you what you really, really want.
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.
There are software development methods where everything is formally defined and there are procedures to test and correct requirements, definitions and implementations at every stage of the project. The best example probably being the methodoligies used by NASA and JPL (Jet Propulsion Laboritory) when wring software for spacecraft. (Even they have bugs!).
The problem is that these methods are painstakingly slow and expensive.
Most corporate/business software is developed using much sloppier "good enough" methodoligies which relies greatly on common sense evaluation and lots of informal communication between the business, analysts and developers.
Specs are just good enough but the authors were known, and, any innaccuracies could be cleared up when you were both at the coffee machine.
This informal communication is completely lost when parts of a project are outsourced.
Sending the same spec to another country to be evaluated by a developer who has
never met the author and who must route all queries through an account manager
just does not work.
When you outsource a project you should be prepared to triple the amount of time and money spent evaluating and revewing all your requirements and specification documents. Except in most cases this will not happen because this willmake it more expensive than an in house development and management will not want to hear that.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
