OUTSOURCE : Competing in the Global Productivity Race (Yourdon Press Computing Series)
by Edward Yourdon
Average Customer Review: 
Hardcover
(04 October, 2004)
list price: $27.99
-- our price: $18.47
(price subject to change: see help)
US |
Canada |
United Kingdom |
Germany |
France
Reviews (12)
The fact is : C-Level Staff Have No Idea how to succeed
First let me say Ed Yourdon is one of my heroes. This is not meant to bash his book as much as to provide a viewpoint that people writing software need to have.
After 15 years in this industry I have seen all of the phases (pre-client/server, to N-Tiered to now Software Factories and MDA). One thing has always been the same: Organizations in general are miserable at writing software. MISERABLE. Not Microsoft, not Oracle, but organizations where Software is not their core competency and software is not their main revenue producer.
CEOs feel trapped as legacy systems must be up (and must be continually maintained, extended and cared for) or they are potentially 'out of business'.New development projects are started without common sense and CTO/CIOs commit to outlandish delivery estimates, with poor staff, cultures that do everything to foster failure, and a general lack of desire to be excellent.
CTO/CIOs are the least likely to be promoted to CEO and the most likely to be fired. There is good reason for this as it is the rare minority that actually keeps learning after a certain point (and it is even worse at the middle management level). The latest Standish group studies show that only 16% of projects succeed and they can only deliver 42% of what was expected of them. The 'Software Crisis' is very real as I see it every day and I am called in to try to stop the bleeding (which I usually can do fortunately for me (grin)).
My theories on why we are in this horrible state are numerous but to keep it short it goes something like this: Software is usually seen as a cost center NOT a strategic asset. Managers are promoted based on coding skills and a complete lack of processes (or Code and Fix as Steve McConnell calls it) rule the day. Managers are even loathe to implement process and often decide on `high ceremony' processes like the Rational Unified Process. These slow down the process, make consultants wealthy and do very, very little to help a project succeed in most cases (of course there are many exceptions). I will get to the answer, in Agile Development, but it is interesting that there is now a `Rational Unified Process - Agile'. Even Microsoft is adopting their Microsoft Solutions Framework with MSF-Agile. These are actually good things.
Software is what is known as a 'wicked problem' in that you cannot know how to build the solution until you start and experience some failures and some successes along the way. Comprehensive and complete upfront analysis and design is statistically proven by a number of research studies to be a recipe for disaster and many companies will box you in to a 'following the plan', marching you right into the ocean, and everyone drowns.
Outsourcing pours gasoline on this fire. You must write such detailed specifications that the system could have been built in the time it take to do so in my experience. Outsourcing does occasionally make sense for MAINTENANCE of systems that are well into their maturity. Where there is little to no innovation occurring and an outsourced group can field the bugs and the occasional (non earth-shattering new feature). But for any new development, forget it.
There is a solution today and a solution that is emerging:
a) TODAY: Agile Programming Techniques do not make false assumptions about the ability to predict the future (how many people manage by GANTT charts running months into the future? They actually commit their careers to them in many sad cases)]. IT managers today are assumed to have magical powers to predict the future. THEY DO NOT. Agile processes such as the excellent work of Kent Beck and Ken Schwaber have set the stage for a next generation in Agile. The `Next Generation in agile' addresses the occasionally valid criticisms (but the majority of the criticisms today are simply people without any first hand knowledge or they are just not reading the literature).
Agile processes are now emerging (this is actually what I am working on in my company and what my forthcoming book covers - and don't groan - I am writing this with no intention to get book sales out of it) combined with a sensible Risk Management framework, with Metrics such as the Core Agility Ratio, to help steer the ship through the timeboxed iterative nature of development, and the proof I offer (and others have nearly reached before me) that Design Patterns are a 'Critical Success Factor' to Objected Oriented Development ESPECIALLY in Agile to reach the `flat cost curve' of change over time.
Outsourcing is a typically a miserable failure as you rarely saves money (due to all of the upfront work in writing specifications, and the most important item in software success is completely destroyed: COMMUNICATION!).
In Agile, you do not assume you can predict that new legislation will not be passed, that a new competitor will not enter your field and change the entire competitive landscape, that your leading 'cowboy' programming expert will leave for another job, etc. Agile says 'OK we know we cannot know all this up front (it would be impossible) so we will not even try, beyond basic planning and short statements of requirements that will be fully defined when we enter the iteration. WE DELAY DECISIONS UNTIL THE LAST POSSIBLE MOMENT ALWAYS. All work will be broken in iterations, each producing working versions of the system and the stakeholders will be able to make changes after each iteration (and during if it is a real emergency). WE EMBRACE CHANGE to paraphrase Kent Beck. So you want to change the requirements around this subsystem? Great! We are ready. So you want to eliminate these areas and add new ones to meet new federal and state regulations? No problem. We are ready for change and we DEMAND that the business commit resources to us so we can build the system THEY want as it will be the business that determines if we are successful.'
Think in terms of time, scope, quality and cost. I tell clients they get to pick three but I control the fourth. If they try to control all four, I walk. I have no interest in failure. For example:
1)You have $1,000,000 to build a production e-Commerce system that will have the quality to scale to 10,000 concurrent users and it must perform these 100 items (which should be short enough to fit on an index card). I never heard any date restriction so I need to assess:
a.How much risk is this client willing to assume (see `Waltzing with Bears')
b.What is the team I have and how can I influence the process for success, by creating a war-room, by being given the control to drive the PROCESS by which we build this software
If the client agrees to accept, say 20% risk, and I can achieve that with the team I have, and I have the process control to make this happen, and the customer realizes we can only statistically predict the delivery date within a few months (we cannot commit to a hard single date) then this would be a project that would likely succeed (of course I have oversimplified this terribly but I have illustrated some key ideas that are lacking today which have caused the panicked run to outsourcing).
b) THE FUTURE: Doing Agile right is hard. Doing Design Patterns, managing developers through the cultural transition to Test Driven Development is hard. It is VERY HARD to build software. The future has some bright prospects:
1)Software Factories from Microsoft in terms of their Domain Specific Language and Visual Studio 2005
2)The MDA initiative from the OMG (which I am less convinced will succeed but I do believe will make positive in-roads)
So the point of all this? YOU CAN SUCCEED IN BUILDING SOFTWARE. Outsourcing will only make the problem go from horrible to incomprehensibly bad for the situations I have described.
Good Observations and Broad Coverage
I really enjoyed the observations and the illustrations. Yourdon explains the value proposition of outsourcing and then explores the impact of the phenomenon on various industries. I very much enjoyed the enlightening discussion.
He totally missed the impact of outsourcing on the ERP Universe (SAP, PeopleSoft, Oracle etc). There is no mention of anything ERP anywhere in the book.
I was disappointed that Yourdon did not cover the IT industry in detail. It would have been great if he took a stab at navigating today's IT World and designated IT job roles that are easy targets for being outsourced, besides data entry jobs.
He has focused too much from the Mainframe Programmer's view point and assumed everyone can relate to it. I felt the advice to be too broad and generic.It is too high level, and does not have sufficient detail.
There are no diagrams, pictures or models of any kind in this book.It is just a straight up discussion on the topic. I would have liked to see a 4-quadrant distribution of various job roles just like Covey's Time Management Matrix.
He defines the problem clearly but is reluctant to go into the details or offer solutions. He just says we are all doomed and there are no guarantees no matter what you do. He does offer some general guidelines such as - work harder, be proactive, be prepared to relocate etc.
A few examples of how people have successfully handled the threat of outsourcing would have been nice.
Hope to see a more detailed coverage in the next book. This is a fascinating discussion that is far from over.
Excellent guide for anyone whose job may be outsourced
Outsource: Competing in the Global Productivity Race is a persuasive overview of the outsourcing phenomenon. Author Edward Yourdon's premise is that outsourcing is not going to disappear anytime soon, and -- given the success that many companies have begun enjoying during the past few years -- it is not likely to level off anytime soon. Outsourcing is now a mainstream phenomenon and is affecting more and more workers, in nearly every knowledge-based sector. In a nutshell, this is Yourdon's book of how to prepare yourself for the inevitable."
For those Americans who would hope their representatives in Washington would get involved and pass laws to stem the flow of jobs overseas, there is little that Washington will likely do to help knowledge-based workers whose jobs are in danger of being offshored. While the loss of jobs is a crisis to many of us, Yourdon makes note of the oil crisis of the early 1970s and a speech that Jimmy Carter made in April 1977. Carter said "If we fail to act soon we will face an economic, social and political crisis that will threaten our free institutions." Nearly 30 years after Carter made that speech, oil is at an all-time high and nothing has been significantly done to reduce our dependency on oil; or to find a better solution.
If Congress is apathetic when it comes to an effective energy policy that affects an entire nation, it is clear that preserving the jobs of C and Java programmers is likely to be at the bottom of any congressman's to-do list. In 2005, national security, Medicare and Iraq are just a few of the issues that seem to be far more pressing to the nation than the loss of programmers.
The book is written about outsourcing in general, but has a heavy slant to programmers whose jobs have been outsourced to India. The prime advantage India has over other countries with cheap labor is a large base of workers that speak English. While the salaries in China, for example, are even lower than in India, the language barrier is significant.
The main claims of proponents of outsourcing are of increased productivity and major cost savings. Whether these claims are real is to a degree immaterial, as the perception among CIOs is that outsourcing has an immediate cost savings. This is primarily due to the fact that the salaries and benefit costs of overseas programmers are radically less than those of their U.S. counterparts.
From a productivity and efficiency perspective, many Indian firms are CMM level-5 certified, something that their U.S. counterparts can't attest to. At the end of the day, is better and cheaper code produced in Bangalore and Mumbai? Yourdon states that it is hard to find hard and fast answers. But with outsourcing the rage, there is the perception that Indian firms are more productive, formalized and efficient than their US counterparts is being accepted as fact. For many, perception is reality, and the reality is that jobs are being sent overseas by the thousands.
Outsource:Competing in the Global Productivity Race is written for (and beneficial to) anyone who feels that his job may be in danger of being outsourced. The book is well-written and pragmatic, and Yourdon notes that there are no simple answers to be found, nor are there any obvious choices. The book guides the reader who is working in a knowledge-based position to better determine where the trends in outsourcing are going and how to best save their job and simultaneously prepare for the inevitable. It is not that every knowledge-based job will be outsourced, but rather that the potential exists that every job could be outsourced. With that, it behooves everyone to get make sure they are prepared.
In 1992, Yourdon wrote Decline and Fall of the American Programmer. In the book, he predicted that U.S. programmers would "suffer the fate of the Dodo bird" as companies shifted jobs from American workers to those overseas to take advantage of lower pay, less labor regulations and higher productivity. Yourdon admits his prediction was partially incorrect. U.S. programmers have not gone the way of the Dodo bird and hiring is resuming; but in spite of everything, huge numbers of jobs are being sent overseas.
While Decline and Fall of the American Programmer was focused exclusively on technology workers, Yourdon writes that every knowledge-based job is vulnerable to being outsourced. From radiologists to tax preparers, telemarketers to architects, and more.
Perhaps the biggest benefit of Outsource is the composed manner in which Yourdon writes. Outsourcing is a controversial, political and extremely emotional topic, and Yourdon provides a balanced view of the outsourcing phenomena.
One of the solutions suggested to stemming the flow of jobs overseas is protectionist federal regulations. Yourdon believes that such measures are doomed to fail, in that you can't protect knowledge-based worked in the same way that steel and agriculture products can be protected. Yourdon admits that there might be some short-term benefits to a protectionist strategy, but will fail in the long-term. His view is that protectionism is simply blaming someone else for the existence of competition; and such an approach does not solve the problem. His solution, and the overall advice in the book, is to make each and every American knowledge worker more prepared to face competition from overseas.
Of the books 10 chapters, the most compelling is chapter 6, which provides seven strategies in which to deal with the threat of outsourcing. The first is to be proactive, with the last being to consider a career change. Yourdon does not promise and secrets or miracles in the chapter and attempts to provide some common, yet often overlooked, sense.
Outsource ends with the following quote: "I was taught very early that I would have to depend entirely upon myself; that my future lay in my own hands." This book shows you how.
... Read more
Reads like an eastern sect literature
