Java Industry News

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:

• 68% of IT executives, responding to a CIO magazine survey, said that outsourcing would likely increase in the coming year; 30% said that it would remain the same.
• The CIO magazine survey further found that 11% of the responding companies had outsourced system and architecture planning and 14% had outsourced research and development - two areas that were once believed to be invulnerable to the pressure to outsource.

The great drive to outsource is based on simple economics. Compare the statistics on American versus the Indian subcontinent (India presently has about 80% of the outsourcing market):

America
GDP/capita: $35,060
Unemployment rate: 5.8%
Labor force: 142 million
Typical salary for a programmer: $70,000

India
GDP/capita: $480
Unemployment rate: 8.8%
Labor force: 406 million
Typical salary for a programmer: $10,500

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:

• Language and proximity differences: Despite the fact that many offshore programmers speak English, the lack of proximity tends to bring out the inevitable differences in idioms, dialect, and pronunciation. When this leads to miscommunication, the costs can be very high.
• Cultural differences: In some cultures, admitting to a lack of knowledge or understanding is a mark of shame, leading to the "nodding head" syndrome when frank discussion and questioning is required. This, too, has a potentially huge and negative impact on the vaunted cost savings of offshore work.
• Time zone differences: From the center of India to the center of America, the time difference is about 12 hours, a perfect offset. This means that there is no time when we share the same workday, forcing communication to be channeled primarily into e-mail and other written forms. But these have a notoriously low "bandwidth," exacerbating the other problems of outsourcing.
• Upward pressure on programmer salaries: Two years ago, programmer salaries in India were only about $8,000 annually. As India prospers, programmer salaries will naturally rise, offsetting some of the cost advantage of outsourcing.
• Loss of critical expertise: If the trend towards offshore development is too extreme, companies may find that they no longer possess needed expertise in-house. Where such expertise is critical, the danger to the company can be enormous.
• Endangerment of proprietary data: Transferring work half a world away necessarily entails giving up some of the control companies enjoy with on-site developers. Additionally, if problems arise, companies do not have the benefit of employing remedies in U.S. courts of law, but are faced with trying to work out the problem at a very long distance.

So, do we have "nothing to fear but fear itself," as former U.S. president, Franklin Roosevelt, once put it? I think the situation is considerably graver than this. While it may very well be that outsourcing turns out to be but the latest management trend du jour, its effects on us developers will be no less profound and it may take years before the ship is turned right.

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.

For too long, too many of us have been relying on knowledge gained years ago. ColdFusion is the only language we know (along with a smattering of JavaScript and SQL). We write the same forms, create similar lists with drilldowns, produce edit screens, and the like. Our knowledge has not kept pace with the changes occurring in our industry. We read that within three years, over 90% of software development will be done with object-oriented languages on either the Java or the .NET platform, but still haven't found the resolve to learn them. If this describes you (to misquote Jeff Foxworthy), you may be a 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
It's been clear for some time that in corporate software shops, coding, as such, is losing its utility value. This is the kind of work being outsourced at breakneck speeds today. Given the low success rate for corporate software, we've got much, much bigger problems than how quickly or efficiently we can write code. The biggest problem is not that we're writing code inefficiently; it's that we're writing the wrong code altogether!

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
The problem with project management is that it takes excellent communication skills as well as other soft skills such as empathy, warmth, and patience. Hey, if you had wanted to do that, you could have become a social worker!

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
If you work for a government agency (or in many cases for a government contractor), you probably don't need to be greatly concerned about outsourcing. Even if outsourcing were to succeed wildly, this work will not be outsourced. This isn't a bad strategy, although you may very well be locking yourself into doing this kind of work for a long time. If you have a constant desire for new challenges, you may feel stultified. But many of us aren't technology junkies and the rewards and benefits can be steady, if not spectacular.

Survival Strategy No. 4: Be a Small Cog
Given the considerable difficulties and expenses in establishing a viable outsourcing relationship, very small companies are unlikely to adopt outsourcing. The possible downside to this strategy is a possible lack of job stability and reduced resources compared to larger companies. Still, in the right position this can be a great strategy. It's also probably the easiest one to adopt. Be careful, though, because this "easier" environment can lull you into lethargy. You'll still need to be vigilant about managing your career.

Survival Strategy No. 5: Become a Subject Matter Expert
When I was young, I wondered why baseball players who played only a single position were paid far more than "utility" players who could play multiple positions. Wasn't more better? The answer then, and now, is "No."

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
This may be the riskiest strategy of the lot. Technology experts are expected to be almost prescient in their ability to rank "winning" technologies. Further, the technological landscape is so vast that no one can be a general expert. You'll have to narrow down the scope of your endeavors.

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
Agile methodologies are a poor fit for the separation of specifications from programming that current outsourcing demands. The best known "agile" methodology is Kent Beck's Extreme Programming (XP) (www.extremeprogramming.org). XP asserts that software development is "about people, not processes." Agile methodologies are very much in fashion right now, but their ability to deliver the quality and type of software needed is still very much a matter of belief rather than evidence.

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.