Outside Consulting Services Considered Harmful

I read this entry on my good friend Guy's blog today, The Threat to India's High-Tech Sector. The threat of Trojan Horse "timebombs" in the code that US corporations are contracting, IMHO, is tremendous, and should scare the socks off every IT manager who thinks they're getting a good deal by having their project developed "cheaply" by an off-shore consulting firm. Any consulting firm, for that matter.

Personally, I am of the strong opinion that mission-critical, competitive advantage software (the kind that my company is having me develop right now) should never be out-sourced to non-employees. Ever. For any reason. Whatsoever. It's hard enough to be sure that your employees have the company's best interests at heart, but I'd say the chances are 1000% better than with some over-worked (hi Dave!) and money-motivated outside contractor. That person only wants to 1) get the damn thing done, and 2) get paid for it. Once paid, they're "outta here".

Bad pizza. Very bad pizza.

As an employee of the company, I know I'm going to be around later. Either I will get the credit, or I will be in the line of fire to get the blame. Either outcome motivates me to do the best job possible, and quite frankly, I'd much rather get the credit. F*cking up only means I get to update my resume and begin looking for a new job. Nah. I'd rather not.

The contractor isn't worried that someone will vilify him later. So what? The client will still hire his company for more work, probably still hire him for more work, so he doesn't suffer the same consequences. In the case of off-shore contracting, the problem is worse, of course.

Not only do the developers not have the client's best interests in mind, they've never even met anyone from the client company, and may not know anything (beyond the most rudimentary things) about the company. So, just how close will the software match the customer's requirements? From my experience, little to none. During development, most of what you must apply as "requirements" isn't written down. But, that's just one problem.

Once the code is delivered, the customer simply runs some tests and then puts it in production. I would be very surprised if they took the code and submitted it to a thorough code review, especially if we're talking thousands of lines of code. As a result, there could be anything in the code. Anything at all. The Marcus J. Ranum article said it quite well, though:

"I don't know. We don't know. In fact, we can't know - if we were to try to audit all those jillions of lines of code we're buying from India, we'd need so many talented programmers it'd be cheaper to write it ourselves in the first place."

But wait, there's more! If the code is run in an untrusted environment with no access to outside resources, then the exposure for information theft (read that as: Very Bad) is small. But, I know how these things are often done. In the Microsoft DNA environment that our company used to use, all components ran as system administrators, which means that the code is run trusted. Then, if the proper firewalls aren't in place, etc., etc. ... well, you've just given the keys to the kingdom to a piece of software written by someone whose political views you don't have a good handle on.

This post isn't a treatise on this subject. These are just a couple of things that I can think of that might be wrong with the move toward out-sourced development. Personally, I'm not worried about my job, at all. I think I can compete with bozos from ... Someplaceistan ... quite well. Some US developers should be worried, though, because if they aren't on their toes and ready to move quickly, they could get run over in the stampede. But, I'm not naming names, or anything.