Outsourcing Waterfall
Outsourcing Waterfallbibo wrote: [Source? -- TheEditor]
market don't send their development work offshore? In all fairness, in spite of the derision leveled at foreign developers out of frustration, their *ARE* - in fact - very competent, professional developers off-shore who could (in theory anyway) do the same quality of work your team does but cheaper
Speaking only of my own experience working within a large IT department (11,000 people) we offshore all large programming jobs and all legacy maintenance. But only the programming. (We occasionally outsource design etc to an offshore company but only by insisting that they 'onshore' their staff... effectively acting like local contractors, but that changes the economics)
We do AnalysisAndDesign? in-house and any quick n dirty jobs or proofs of concept. We also do any new technology stuff in-house first time to make sure we understand what we are talking about when we get round to offshoring the next one...
Most of the department now act purely as designers, architects, project managers, test managers etc... Whereas we used to have I'd guess 40% of our people basically writing code, we now have about 10%. Apart from the few who really enjoy the act of coding most folks see this as an improvement since the design/management type jobs tend to attract better salaries in the marketplace.
The areas where offshore workers cannot compete are
1) projects that require local context. ie understanding of local culture or geographic knowledge etc.
2) Projects with high degrees of churn in requirements. The need to interact with the client and make very fast changes means the added logistics of dealing with offshore staff is unacceptable.
Finally let's not forget human prejudice. Some clients will not want the work being done by particular racial groups for whatever personal reasons...
Otherwise offshore is an excellent source of highly skilled programmers.
Alan G.
I'm speechless. Lean design techniques would reduce the workload. Instead, they use WaterFall in exactly the way known to increase workload, then they outsource the flab into the cheap labor markets.
And it works for them. Your point being?
Mr Manners reminds the Gentle WikiZen (s)he might be trying to say "could this page have a more accurate name?"
This Wikizen might have been attempting to administer a ZenSlap. Minimising overall workload isn't automatically the optimal solution in all cases
Apart from the few who really enjoy the act of coding most folks see this as an improvement since the design/management type jobs tend to attract better salaries in the marketplace.
It's not surprising that you have only a few people who really enjoy coding, considering the low value your corporate culture places on it. If not holding a design/management-type job means that one is going to have their job outsourced, then of course your people will want those jobs.
Alan G. replies:
You make big assumptions, in fact we use DynamicSystemsDevelopmentMethod as a "managed" LightweightProcess?. We also use a wide variety of design techniques ranging from skunk works to clean room. Our projects range from large (>1000my) mainframe projects to small embedded systems in assembler. We include several safety critical systems which use formal specification methods (Z, VDM etc)
"architects" who don't code, and they throw specs "over the wall"
The architects don't code as such (personally I use Python to write quick proof of concept prototypes) but on the scale of projects we are doing it would be ludicrous to have architects coding - what would they code? Often an architecture project doesn't involve coding but simply going out and buying a package... Most of the work is in writing the spec for the ITT.
As for throwing over a wall, who says? The architects and designers will be in weekly contact with the coders, often daily. Ad that's no different to the designers themselves who are often scattered across the country, sometimes in several countries! Each has their own area of specialism - networks, routing, accounting, B2B, CRM, etc... We now have the technology that distance need not be a huge barrier to communication - look at how open source development happens!
You outsource your process flab into the cheap labor markets.
We outsource work that has to be done. Writing the code is not flab, its essential. But if the code is properly specified - and it must be for future maintenance (most of this stuff has a lifetime in excess of 20 years) - then the coding can be outsourced.
You over-staff to clean up after the "design phase",
I wonder if you have ever worked on a large sysem? One where there are maybe 20 sub systems to be integrated with each sub-system comprising maybe 500,000 to 10,000,000 lines of code. Something like an international air-traffic control system say...? Or a military communications hub? Or even the control systems of an airliner? Or a telphone switch?
The pragmatics of building such systems mean that XP and Agile methods etc can only be used at the very lowest levels of granularity. This is acknowledged in the XP literature.
But good luck finding anyone capable of telling you this in a much politer way that won't turn you off!
Not at all, we have, after all, evolved to this state. We didn't just decide, "Oh heck, let's just outsource the coding!" It was done gradually over a 5 year or so period and the result was that we now deliver faster (and with fewer bugs!) than we used to. And that's based on collected metrics not guestimation or gut feel.
Alan G.
Fortunately, just then one JamesMcGovern came to Alan G.'s rescue, by posting the following to another forum or three (excerpted):
The idea of agile outsourcing came to me after finishing up my latest book: JavaWebServicesArchitecture? (ISBN 1558609008 ) and in having discussions with ScottAmbler. Having received large acceptance of this book by outsourcing firms overseas such as Wipro, Covansys, Tata, IBM, EDS, CSC and others, I realized there was a common problem and sought the solution to it.
...When working with an outsourcer once should mandate frequent releases of software. An agile enterprise will never let themselves not see working software for any more than two weeks. The more frequent one sees working software, the better...
...The goal of this forum will be to further expand the industry's thoughts of better ways to merge agile methods with outsourcing. I welcome you to join the Agile Outsourcing Yahoo Group at: http://groups.yahoo.com/group/agileoutsourcing .
Non-iterative processes are sensitive to initial conditions, and they amplify the effects of poor communication. Outsourcers, familiar with WaterFall generally working, might then blame the vendor team, instead of WaterFall itself:
"How Offshore Outsourcing Failed Us" http://www.nwc.com/story/singlePageFormat.jhtml?articleID=15201900
Augh, what AlarmBellPhrases!
A Web site for "$20,000, with a nine-week time line". Those cheapskates got what they deserved...
Then - guess what? - after the "BigBangTesting phase", the local QualityControl team found a zillion bugs!
Did the Indian side have colocated QC? If the programmers switched to the QC role, their knowledge of the code subconsciously prevents them from "clicking on the wrong button at the wrong time" - everyone knows this!
Conclusion: The 'Merrikan side projected their ignorance of software lifecycles onto an Indian team trained that "the customer is always right". They denied the team authority over process, or even design, and imposed responsibility to produce code without real reviews, under absurd constraints.
Incredibly, the author of that article concludes that granting less authority, and imposing more responsibility, could have somehow fixed the situation!!! Unbelievable.
This post-mortem reveals interesting project life-cycle problems, but outsourcing wasn't one of them.
See also SoftwareLabourers, ArchitectsDontCode, InternationalOutsourcing, AgileOutsourcing?.
EditText of this page
(last edited February 18, 2006)
or FindPage with title or text search