bibo 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 . -- JamesMcGovern ---- 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 AlarmBellPhrase''''''s! A Web site for "$20,000, with a nine-week time line". Those cheapskates got what they deserved... * "An on-site liaison, supplied by the vendor". ** Okay. Instead of sending a domain expert to India, they brought an Indian to 'Merrika, and called ''this'' situation a liaison! * "An on-site business analyst" from the vendor came to 'Merrika, then "returned to India to act as offshore project manager." ** So far no domain expert from the home office has gone to India. (I would sure as hell have taken a long paid vacation in a beautiful tropical country!) * "An offshore project manager tracked tasks and schedules for three offshore team members: a Java developer, a JSP developer and a tester" ** Did she or he track results? Or just what they said they were doing? * "A Life Time software manager ... to provide" remote "code reviews, database design and general advice". ** Did they run the actual program? or review its code? where were its tests? * "The vendor's business analyst ... worked furiously to document all the functional and user interface requirements within four weeks". ** So on a nine-week schedule, they burned 4 doing "big requirements up front". Or else it was really an 11 week schedule, but they only paid the remote team for 9. Did they focus on the highest priority business function, and send that to the team first? * "Determined to dazzle us with their software prowess, the offshore developers insisted on completing the entire code design before allowing us to review it." ** Okay. First a blackout without even documentation feedback, and then a review of the design for a design, not the real thing. * "Tragically, our review determined that the offshore team's design patterns weren't in accordance with the standards Life Time follows" ** Besides mis-using the sacred word "DesignPatterns", what kinds of standards were these? Why wasn't the remote team granted authority to design how they saw fit?? And how many of the subsequent bugs did "fixing" these problems cause? * "The offshore team began working extra-long hours to avoid asking for a time extension". ** Oookay. The 'Merrikan brass flew to India for a meeting, but the post-mortem doesn't say if they reviewed the working program. (It's a Web site for cod's sake - they could have reviewed it on their extranet!) 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.