Tuesday, January 26, 2010

The O-Word

Information Technology in North America is going to the dogs. Once upon a time, getting a computer science or computer engineering degree actually meant something. Then everyone and their brother thought they could be a software developer by taking some course at some crappy community college. And then it got worse. Some companies (like one of my former employers) believed that they could train any person with half a brain to do development. All of a sudden, we had people who had NO BUSINESS writing code, let alone touching a computer become developers. "Don't worry," they were told. "It just a stepping-stone." What the hell?

I have an engineering degree. I have spent my entire career in IT, including all of my summers as a university student. I've seen good code at work. I've seen bad code cause near catastrophes. I've seen my fair share of mismanaged IT projects (99% of them). So forgive me for thinking that treating development as a "stepping stone" is absolutely absurd. Development is a craft. Good code is like composing a great symphony or painting a masterpiece. When done properly, it can be elegant, efficient, and maintainable.

Unfortunately, the corporate higher-ups think of development as a commodity. Several years ago, in my consulting days, I remember a client saying that, "Anyone can develop. It's the business analysts who do the REAL work." I really really really wanted to call BS on him. In fact, I'm still kicking myself for not having said anything. Don't get me wrong. Business analysts do important work. They gather requirements and produce functional designs. Their work is the input for our work. But developers take those functional designs and turn it into a deliverable. Whether it's an online bookstore or some batch process that updates inventory at the end of the day. Developers produce the ultimate deliverable. So no matter how good the analysis and requirements phase is, if you don't have a good development team on board, your project is doomed for failure.

And yet, almost every IT project that I've been on seems to be doomed for failure because management sets it up for failure through one or all of the following: understaffing, compressed timelines, and my favorite one of all: outsourcing. Yes, the O-word.

IT outsourcing invaded the North American market in 2002 or 2003, if I recall correctly. I was pretty outraged then. As a young developer, it appeared that my job was being taken away by Indian developers. We were told not to worry. Leave the drudge work to the offshore developers. That way, onshore resources could focus on management skills. Sounded like a recipe for disaster. And it was. And is. And yet, the model continues to flourish.

Offshore resources are stealing our jobs, and not only that, because of the ridiculous time difference, we must also accommodate to their schedule. What the hell is up with that. Why is it that some dude who is stealing work for me is forcing me to be on a conference call at 7am? Just so he doesn't have to be in the office past 7pm? If they work for us, then they should keep our hours.

Anyone who has worked directly with offshore resources will tell you the following:

1. Offshore resources are typically crappy developers. And why is that? Because the jobs are plenty, people are plenty, and their rates are CHEAP. So cheap that it is still worthwhile to hire a bunch of crappy developers, have them develop a crappy system, and then have them fix it over and over until it (sort of) works than hire a good team of onshore resources.

2. Offshore resources are like automatons. I agree that when a technical design reaches the hands of a developer, it should be pretty sound. Newsflash: even great developers can make bad design decisions that aren't caught until someone actually sits down and starts coding. It happens to the best if us. It even happened to me recently. So if you've got some offshore code monkey writing code based on a design that makes no sense and doesn't question it, then you end up stuck with a bad product.

3. Bad offshore development is always covered up. Executives are so gung-ho on making their huge margins on offshore development that they will do almost anything to keep this bad model going. This includes having onshore resources ultimately having to fix the really bad offshore code. And worse yet, management never admits to the client that they had to bring in onshore resources to fix the bad offshore code.

So on the outside, it looks like a successful model because the product gets built and the margins are beefy. As a result, the model that should have gone the way of the dodo is flourishing. And expanding. I've heard from friends that it's not just the development jobs being outsourced. Now, even business analyst and software architecture jobs are being outsourced too. Pretty soon, we'll be left with no IT jobs to speak of. And then what? All I can hope for is that the outsourcing goes so far that even upper-management jobs get outsourced, sending unemployment soaring to new heights, so that IT jobs can finally be returned to where they belong: onshore.


Peter Lo said...

This is an excellent post. You can count me as someone who agree and witness 100% of this. One of my managers told me that in a conversation he had with our offshore resources, they consider someone to be a "senior developer" if they have 3 years of experience. 3 YEARS!!! Honestly, I'd consider that to be the start of being an intermediate, but that's just me.

MBA programs all over teach their students that outsourcing non-core assets to be the key to running a successful business. There is some merit to the idea, but the flaw in it is how a business defines "core asset". More and more, many businesses find ways of defining various skillsets and business units out of its "core assets" in an attempt to lower their resource expenses.

Furthermore, I'm more than convinced that "quality of product and service" is not reflected in their resource budgets or bottom-lines. As far as they're concerned, having buggy code in products and services simply means having opportunity to charge support costs on the customer in the future. (But perhaps I'm just being cynical.) Anyways... I'm not so sure bad offshore development is covered up, as they are simply not considered in the equation. Code and service delivered is "success" regardless of quality.

All that said though, many of the business divisions in my workplace is starting to move off of outsourcing to offshore resources, and the few that still do, they outsource to onshore resources who have been onshore so long, they mind as well be full-time regular contractors.

I long for the days when "coding" is considered a true craft once again, and not simply monkey labor. I like to think that I'm pretty good at what I do, that what I do requires a level of creativity that is not easily replaceable just by anyone. But ultimately, this speaks more about what a company's C-level personnel's technology philosophy is. Are they a tech-company that provides service? Or a service-company with tech-resources?

IndyComp0T1 said...

Thanks for posting your thoughts, Peter. I can only hope that someday our beloved profession will be taken seriously once again and will be placed in the hands of competent professionals, rather than a bunch of indifferent automatons.