Most Read This Week
Java Industry News
Seven Strategies for Surviving Outsourcing
Choose the one that works for you
By: Hal Helms
Jun. 22, 2004 12:00 AM
One of the most enduring of American legends is that of John Henry, the "steel drivin' man," who pitted his strength against a machine - and won. Unlike many legends, John Henry was a real person - a former slave who was hired by the C&O Railroad to cut holes in rock into which explosives were placed in order to create tunnels. It was slow, difficult, dangerous work and John Henry did it better than anyone.
One day, a salesman came to John Henry's camp and boasted that his steam-powered drill could outwork any man, and the now-famous contest was on. John Henry won the race, drilling fourteen feet to the machine's nine, but his victory was short-lived as he died a few hours later from the stress of the competition. It's ironic, but the best thing for John Henry's reputation was his death after that victory. Had he lived, he would have seen his value as a worker diminish to be replaced by a faster, cheaper, and better method.
Today, many coders are caught up in a John Henry-like struggle. The opponent is not a steam drill but outsourcing. Five years ago, developers heard about offshore work that was being done, but the reality was still distant. Today, it is far more real as many of us have either experienced outsourcing directly or know someone who has. We can only wonder what the outsourcing situation will look like five years hence, but we do have some clues.
The Gartner Group, a highly respected IT prognosticating firm, estimates that within five years, one half or more of programming jobs will leave North America. In an interview Lou Dobbs of CNN had with a Gartner Group vice president, the VP stated that even with the problems of outsourcing, which are very considerable (and often overlooked), the cost of producing the same software offshore costs 40% of what it would cost if done domestically. But far more alarming, the quality of the offshore-born software is higher, as measured using the Capability Maturity Model (CMM), a well-known metric for establishing software quality. With the economics seeming to be so compelling, it is likely that managers will have to justify a decision to not outsource.
The upcoming U.S. presidential election has put the issue of outsourcing squarely on the table. After a brief period where programmers were the star of the "new" U.S. economy, IT jobs have steadily declined. Just how bad is the problem? Consider these facts:
Given these facts, it's no wonder that Indian software exports are over $10 billion annually - and growing at a 30% pace. Still, not everything drives software development eastwards. There are some significant negatives associated with offshore development, including:
Many of us concerned with the effects of outsourcing fail to see the cause of the events that distress us so greatly. The great dot-com bubble was the culmination of attitudes that many of us have held dearly, one of which was that as developers, we have an inherent right to be paid highly. And why not? Software underpins the economies of all highly-developed nations and who writes that software but us?
What we failed to see is the extent of our failure in writing this software. Repeated studies have shown that, at best, the success rate for custom corporate software is no more than 30%. Individual programmers continue to believe that their software is the exception to this rule, but this is nothing but the Lake Wobegon effect, where everyone is above average.
One CTO e-mailed me this about the reality he perceives: "I think our programmers really don't know the skill gap that exists between them and our overseas people. The local guys' knowledge really hasn't kept up with what we're seeing from India - but they still want high U.S. wages." The main lesson of outsourcing for all of us, whether we're in favor of it or not, is that this situation (low success/high wages) can't continue.
Where does this leave us? Are we laboring like John Henry against forces too powerful for us in a valiant, but doomed, effort? It will be helpful if we can more precisely define the problem. Exactly which jobs are "outsourceable?" Most analysts have identified vulnerable jobs that can be precisely defined and made into a routine. These are the "low-hanging fruit" of outsourcing. Since these jobs use workers as cogs in a machine, it's no surprise that the cogs tend to be interchangeable. Remove one expensive American cog; replace with one cheaper Indian cog.
A biologist friend of mine is fond of saying that the law of life is: "adapt or die." In biological systems, it's the environment that goads organisms to change, to adapt, and to grow. There is, it seems, something good about an environment that pressures us to adapt or die, as American car companies found out when their cozy environment was upset by the explosion of Japanese cars into the American market. They became leaner, better focused, and, ultimately, more profitable. Welcome to the jungle.
The reality of outsourcing is the reality of the environment telling us, "adapt or die." But how? What actions shall we take? Put another way, if we are to escape being cogs, what shall we do? So what's a cog to do? Below, I've listed several "strategies for survival" specific to the new environment we face. Most of them will require significant commitments from us and, for all of us, education - effective education - will become preeminently important. I've given them numbers, but the order in which they appear is not meant to imply that one is a better strategy than another.
Survival Strategy No. 1: Get into Project Management
But many coders don't feel that they have much say in the ultimate success of a software project - and to be honest, many of us don't enjoy the type of work that project management entails - we just want to write code. Whatever the future of outsourcing ultimately is, I think it's a very safe bet to say that defining ourselves simply as "coders" is a losing strategy. This is the lowest of the low-hanging fruit in the IT world. And coders face the greatest threats, for not only must they be concerned with their jobs being outsourced to other humans, but the reality of machine coders draws closer each day. From smart IDEs to tools for Model Driven Architecture (MDA), the value of the ability to translate a natural language into code is being continuously downgraded.
When I teach my "Project Management with FLiP" class, I'm often asked what I think the greatest key to successful projects is. Is it the choice of language (Java versus ColdFusion versus C#)? Is it the database (Oracle versus SQL Server versus DB2)? Is it the skill of the coders?
In my experience, it's far more fundamental: neither we nor the users really know what needs to be written. The project requirements are vague and usually don't come into focus until the project is actually delivered. I've written extensively on the need for prototyping as an essential skill for project success. But the temptation to hurry the process can, for many programmers, be all but irresistible: we just want to start coding. If, though, you can successfully learn proven, successful project management skills, you can write your own ticket and will not need to worry about your job being sent anywhere.
Survival Strategy No. 2: Develop the Skills of a System Architect
For many of us, the technical challenges of software have a great appeal. We find them intellectually stimulating and the thought of giving this up is an unhappy one. The good news is that you don't need to give it up; you just need to plunge into it even more deeply.
People who can design software systems are exceedingly rare. The ability to make large-scale technical decisions has great value in any conceivable world that involves software - wherever it's actually written. If you decide to go this route, you need to understand that you're committing yourself to deepening your knowledge considerably and keeping it up to date. This is not an easy task, but it can be an extremely rewarding one. Just make sure that you don't kid yourself about your current abilities. I meet a lot of people who are good at writing code who assume that this qualifies them as system architects; it doesn't - nor does being fully acquainted with the latest buzzwords.
If you're interested in this (and after you've mastered object orientation), I advise learning about design patterns. The great physicist, Sir Isaac Newton, once said, "If I have been able to see further, it was only because I stood on the shoulders of giants." Design patterns can provide us with those "giants' shoulders."
Understanding and working with design patterns can help you avoid mistakes while guiding you into good solutions for recurring problems. The risk in design patterns is getting carried away by the buzzword aspect. While others use buzzwords and acronyms to represent a knowledge not truly gained, our goal is to gain a deep understanding of design patterns. Warning: the bible for design patterns, Design Patterns, by the so-called "Gang of Four", is not light reading. But you should expect to do a lot of this if you're going to take up the system architect strategy.
Survival Strategy No. 3: Good Enough for Government Work
Survival Strategy No. 4: Be a Small Cog
Survival Strategy No. 5: Become a Subject Matter Expert
Specialists are valuable because they understand the intricacies of a specific problem and can hopefully see more clearly the solution required. Because their expertise is limited in scope, it should also be deeper and that depth of experience can have a great impact on the success of a project.
That's the rationale behind the SME - the subject matter expertise. If you possess a depth of knowledge about, for example, a specific industry, you are likely to be immune to the threat of outsourcing. The key to this strategy is a true depth of both knowledge and experience. For instance, if you've worked extensively with banks, you'll recognize the unique challenges of banks and be in a position to help avoid costly mistakes.
The downside to the SME is that you may need to work more on a contract basis than as a full-time employee. If that suits you, and you possess the necessary skills, being an SME can be very lucrative. Of course, you'll be expected to keep abreast of both the current and the potential changes to your subject matter.
Survival Strategy No. 6: Become a Technology Expert
Establishing yourself as a technology expert can also be tough. What makes someone a real expert instead of someone who understands enough about a lot to talk a good game isn't clear at first. You may find it hard to establish yourself in this strategy. If you do go ahead with it, work on getting published. You'll need to be able to count on some name recognition to make this strategy work. And remember, you're trading on people's trust in your ability to make good evaluations under great pressure. That means occasionally taking positions that may be unpopular with people above your pay grade. Better sharpen your political skills while you're at it!
Survival Strategy No. 7: Find a Company That Uses Agile Methodologies
If you do work for an "agile" company, and if that company succeeds in its purpose for adopting agile methodologies, you'll likely have little to worry about. If you choose this path, you'll want to become as adept at agile methodologies as possible. In fact, you may be able to transform your current company into the company you're seeking. Realize, though, that this is a high-risk strategy and relies, to a great degree, on the perception of success with agile approaches within the management world.
While I don't pretend that this list is all-encompassing, it is at least interesting to note that nowhere does the most pervasive strategy appear: Do Nothing and Hope It All Works Out. Even if claims for the pervasiveness of outsourcing turn out to be wildly exaggerated, is it really likely that staying with a "more of the same" strategy will help us weather the next, inevitable shock to the system? In this regard, and if we allow it to, the wake-up call of outsourcing can prove to be extremely beneficial to us, whatever the future holds.
Perhaps you've come up with another strategy, one better suited to your particular skills and shortcomings. The most important thing is that you carefully consider your options, choose a strategy that works for you, and then act on it. Take very seriously how you will implement your plan. If it requires new knowledge (which it almost certainly will), map out a plan for acquiring that knowledge. In short, don't wait for a catastrophic event to compel you to action.
For further reading, I recommend all of the excellent books from Tom DeMarco. Ed Yourdon's classic, Death March, still has excellent insights, and Eli Goldratt's Critical Chain is particularly thought-provoking. Virtually anything by Edwards Deming will help you understand why projects so often fail, and what you can do about it. For continuing thoughts on, and strategies for, the challenge of outsourcing, please subscribe to my spam-free "Occasional Newsletter" at halhelms.com.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads