Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
The Pulpit

<< [ Body Count ]   |  May the Source Be With You  |   [ Stream on ] >>

Weekly Column

May the Source Be With You: IT Productivity Doesn't Have to Be an Oxymoron, but Outsourcing Isn't the Way to Achieve It

Status: [CLOSED]
By Robert X. Cringely

India, outsourcing, and the concept of IT productivity were the topics here last week, and there is so much more to be said. But first there is that computer pathogen du jour, the pesky MSBlast worm to be dealt with. This was an old story before any of us even read it this week. That darned worm, which exploits the recently discovered RPC DCOM vulnerability in Windows, has been creating a lot of trouble for no good reason. It targets TCP port 135. Why would any company have port 135 open to the Internet? It makes no sense. A competent network manager who is not using port 135 for something darned important ought to have that door locked tight. If your network was affected, you should be asking why.

Microsoft distributed a patch for this bug a month ago. If your network was affected, the patch wasn't installed. What took so long? But don't be too quick to blame your network administrator: In some companies, the data security guy has to approve a patch before the network guys can install anything. There is plenty of blame to pass around.

Microsoft is hardly blameless, either. A very good friend of mine (one of Microsoft's major customers at the time) recommended to Redmond precisely the e-mail safeguards that would have made this week's problem impossible. Since he was a big customer, they said they'd look into it, but did nothing. That was in 1991. Is 12 years too long to wait for vendor responsibility?


Now back to India, outsourcing, and IT productivity.

First, a trick question: Why aren't Apple Macintosh computers more popular in large mainstream organizations? Whatever the gigahertz numbers say, Macintoshes are comparable in performance to Windows or Linux machines. Whatever the conventional wisdom or the Microsoft marketing message, Macs aren't dramatically more expensive to buy and on a Total Cost of Ownership basis they are probably cheaper. Nobody would argue that Macs are harder to use. Clearly, they are easier to use, especially on a network. So what's the problem? Why do Macs seem to exist only in media outfits?

Apple is clearly wondering the same thing because the company recently surveyed owners of their xServe 1U boxes asking what Apple could do to make them more attractive? For those who own xServes, they are darned attractive -- small, powerful, energy-efficient, easy to configure and manage, and offering dramatic savings for applications like streaming. Yet, Apple appears to be having a terrible time selling the things.

I used to think it came down to nerd ego. Macs were easy to use, so they didn't get the respect of nerds who measured their testosterone levels by how fluently they could navigate a command line interface. Now, I think differently. Now, I think Macs threaten the livelihood of IT staffs. If you recommend purchasing a computer that requires only half the support of the machine it is replacing, aren't you putting your job in danger? Exactly.

Ideally, the IT department ought to recommend the best computer for the job, but more often than not, they recommend the best computer for the IT department's job.

Now another question: Why are Linux computers gaining in popularity with large organizations while Macs, which are based after all on BSD Unix, aren't? While there is certainly a lot to be said for Linux in competition with various flavors of Windows (Linux is faster, more memory-efficient, more secure, has more sources of supply, supports many more simultaneous users per box in a server environment, and is clearly cheaper to buy), the advantage over Macintosh computers is less clear.

Again, it comes down to the IT Department Full Employment Act. Adopting Linux allows organizations to increase their IT efficiency without requiring the IT department to increase ITS efficiency. It takes just as many nerds to support 100 Linux boxes as 100 Windows boxes, yet Linux boxes are cheaper and can support more users. The organization is better off while the IT department is unscathed and unchallenged.

I am not claiming that every organization should throw out its PCs and replace them with Macs, but the numbers are pretty clear, and the fact that more Macs don't make it into server racks has to be based on something, and I think that something is CIO self-interest.

Macs reduce IT head count while Linux probably increases IT head count, simple as that.

I didn't come up with this very smart idea, it came from a reader. That same reader made the point that every part of an organization ought to be concerned with improving the bottom line, which is to say with being more productive. Yet IT typically doesn't work that way. Since we can't effectively retrain IT, we outsource it, but that's no better. Costs may appear to go down, but overhead inevitably rises even when the real work is moving to India.

Some people dispute my claim that moving work to India increases overhead. Well, overhead rises whenever layers are added to the network stack. If you move IBM to India there is no increase in overhead. But if you move a big chunk of IBM to India, but keep the rest of IBM where it always was, you have to create an interface layer simply to decide what information goes to India, what information doesn't, and how does the information that does go to India (or comes back from India) get where it should go? That's extra overhead and it costs money -- U.S.-scale money because this bit of overhead takes place here, not in India.

And this leads us to why many development efforts of western companies in India don't work out. The problem with Indian software development is typically two-fold. In one sense, the Indian developers can't relate very well to the foreign end-users (us), and that can lead to problems. But far worse is a problem that is almost the opposite: The Indian coders are treated as just that -- coders -- with all architectural decisions being made 12,000 miles away. There is virtually no input to the architects from the coders because none is sought. That means problems that ought to be noticed early -- and probably are, but in India, not the U.S. -- are noticed too late.

One solution is to allow the Indians greater autonomy, but I think the best solution is to make the architects, whomever they are, live with the coders -- something that is literally NEVER done.

So outsourced IT is less efficient, but with those low Indian wages it certainly must be cheaper, right? Not necessarily. Let's look at the situation that brought us to this topic in the first place -- IBM's apparent decision to send IT jobs to India. These next few paragraphs are IBM-specific, but I am sure they could be applied equally well to many other large IT organizations. Are you paying attention, EDS?

Businesses are successful when they sell products and services people want. IBM's greatest problem is they have not placed any internal value or importance on the quality of their products and services, only costs. Look at how this focus on cost not only hurts products and services, but actually drives up the very costs it is supposed to be bringing down.

There are many people in IBM whose job it is to smooth things over. These folks don't contribute to any product or service, and if the products or services were better, these people wouldn't be needed at all. I call this the CYA Layer, and all it does is make outsourced IT that much more expensive for no good reason.

Part of the myth of IT outsourcing is that it saves money because you only pay for big brains when you need big brains, but that's not true, either. In the IBM example, you only get the brains if you're will to pay for consulting services. For every hour of brains, you will be charged three hours. The other two hours go to management and project management, which is to say they are wasted.

I even have doubts about the quality of those brains, too, not just at IBM, but at virtually any of its competitors. That's because the financial model for outsourcing doesn't pay to maintain education and certification. IBM cut most of that a couple years ago, and the rest of it went this year. In another year or two, most of IBM's MSCE's will have expired, for example. The ones that will remain will be those who paid for it out of their own pockets. Where are the brains in that?

The answer to IT productivity is to first decide who the customer is, and that isn't the CIO, it is the CEO and the janitor and anyone in between with a computer. Once we all agree on who is the customer (something most organizations never do), then purchasing decisions get easier. Truly useful products are bought when they are needed by customers. Now there's a brainstorm. And while you can outsource IT to Boston or Bangalore, today it is probably cheaper for a good-sized company to hire six to 12 smart people, empower them, keep their training current, and have them run the IT organization. A few smart leaders with a good pool of contractors can do a better job with open source support tools than IBM or any other outsourcing vendor can with its proprietary tools. That is because your IT department will better know your needs, and will have those needs at heart IF YOU MAKE THEM DO IT THAT WAY.

What's ironic in this IT outsourcing is that the end game has not the big U.S. companies winning, but their Indian subcontractors. This isn't rocket science, and the Indians are going to quickly see that they can cut out their U.S. employers and go directly to the customers. It won't happen immediately, but eventually every U.S. outsourcing vendor will try to bring the work back in-house for this very reason. And we'll be paying for it all.

Comments from the Tribe

Status: [CLOSED] read all comments (0)