[nathanb]

This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore.

Either he was deluded at the time and overcame his delusion without ever realizing he was deluded (which is possible) or there's more to it than you make it seem. Because I think someone who says "this used to work and now it doesn't" may have something profound to say that the person saying "this has never worked" needs to hear.

Perhaps you're right and software outsourcing has never worked, in the sense that from a total cost standpoint it has never been better to contract development of a software project to a third party than to create it in house. I don't agree with this, but we'll accept it for the point of argument. You're still ignoring his point that the change in economics has caused a cultural change in the attitudes of those who lead outsourcing entities.

The article claims that previously, the economics allowed them the luxury of trying to deliver a result to their customers. Now, they are not able to do so because the economics require them to milk their customers for every cent in order to break even.

This may not directly affect you if you have always believed that outsourcing doesn't work and you disagree with his opening statements attempting to rebut that mindset. But it's still an interesting view from the inside.

[sheepmullet]

> This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore.

Reading between the lines, it "worked" because it was an incredibly high margin business and so when a project wasn't on track they could simply throw many more developers into the mix to get it over the line.

> Either he was deluded at the time and overcame his delusion without ever realizing he was deluded

Or I suspect they simply have a different idea of "worked".

I suspect the OP means was better (I.e. Cheaper, quicker, or of a higher quality) than an internal team could do. Whereas I suspect the writer meant he could keep clients reasonably happy and deliver ok software.

[gaius]

The sort of person who outsources will say whatever is most profitable for them at any moment in time.

Right now he'll be hoping to profit by bringing things back in-house so they can be outsourced again later.

[makecheck]

At the end of the article, his explanation of how this used to “work” is based on what developers were once paid. Cost is a tricky thing to sum up because if you state just one thing (monthly rate, as he did), it's easy for other costs to be left out.

It is entirely possible to pay less for the same talent. My thinking is that he got lucky though.

If you start out underpaying, you can still overpay thereafter. Here is a quick top-of-my-head list of major software costs that can come up (not too far) down the line, after paying initial development wages:

- Documentation turns out to be nonexistent or written in a way that is hard to decipher, or wrong. (This seems more likely with outsourcing because heck, you didn't specify that you wanted the code documented, and it'll take hours to add all that, plus you might pay more later if it's not there...)

- Serious bugs are lurking that require a little time to discover.

- Although the system demo'd well with initial tests, it collapsed when asked to scale slightly; e.g. it exposed a bad choice of algorithm that blew up with large N. Sometimes bad algorithms from inexperienced developers can create a catastrophically large amount of refactoring work.

- The developers took short-cuts and exposed the company to a legal minefield (e.g. copying something or injecting patented or GPL'd code without asking), rendering their working and brilliantly-implemented solution unusable. Now what...even if you can argue that it's their fault, you're probably going to be paying lawyers for something (defense or lawsuits).

- The system does seem to do what it's supposed to do but it turns out you didn't specify it quite right and it integrates poorly into your environment in some way. So, great: it's done, it's here, it runs but you still aren't getting anything out of it because you have to spend more time and money to bring it to a usable state internally. Typically this doesn't happen with internally-developed systems because the people are familiar all along with the idiosyncrasies of the environment.

Even at a cheaper hourly rate, how many more times are you going to go back to the provider (just a few more hours at a cheap rate to fix the next problem...) before you've gained nothing? Much less the fact that you have zero actual employees who understand what you bought so if the provider ever goes out of business or triples its prices, you incur another "new" cost: hiring or redirecting your own people to figure out this thing that you bought and now have to maintain yourself.