Fog Creek Software
Discussion Board




Simple reason why Outsourcing is problematic


I read in the Mythical Man Month that the breakdown of time on development is something like:

*Design/specs:  30%
*Testing & Debugging: 30%
*Coding : 20%
(I think the rest was maintenance).

Design needs to be done by somone who understands the problem domain (e.g., if it's education software, that person should understand education and the target user).

Testing should be done by the designer b/c the goal is to see if the program has bugs AND that it meets the specs/requirements.

Debugging could be done by the developer.

So, you might be able to outsource about 30% of the project. So if Outsourcing had a ZERO COST you'd save 30%.

Mr. Analogy
Tuesday, July 13, 2004

Execs don't want someone who understands the problem domain.  They want someone to put the 'OK' button where they say.  Eventually you're right, there will be repurcussions, but they're not concerned with that now, as they're not even aware of the problem.  Generally speaking.

muppet from forums.madebymonkeys.net
Tuesday, July 13, 2004

BTW, I'm completely agnostic and pragmatic on the outsourcing issue. I'm a Libertarian and support free trade.  I own my software company.

I'd LOVE to outsource but I see a lot of problems with it.
I think you can outsource mediocre, simplistic software, but not anything truly great.

Mr. Analogy
Tuesday, July 13, 2004

It's easy to support outsourcing when you're on top of the dog pile.  :)

muppet from forums.madebymonkeys.net
Tuesday, July 13, 2004

I don't know, check this article out.  The crows are coming home to roost.

http://www.crmbuyer.com/story/35088.html

"The Downside of Offshoring"

http://badblue.com/blog
Wednesday, July 14, 2004

If you outsource, your specs have to be more explicit and detailed, so the ratios become more like this and you save even less:

*Design/specs:  45%
*Testing & Debugging: 20%
*Coding : 15%
*Other/maintenance : 20%

NoName
Wednesday, July 14, 2004


I think as long you can clearly delineate the specs, it shouldn't be much of a problem to outsource (offshore or not) the development of small portions of any given system.

I believe that as the size of the outsourced portion increases *or* it's number of interactions with other portions increases, it will quickly become a nightmare.

KC
Wednesday, July 14, 2004

Come on.....majority of the projects especially in the corporate world are either maintenance of existing stuff or small incremental enhancements and hence the percentages do not hold.

What you say is true for new projects or major rewrites of existing projects  but that is not the bread and butter area in which many software engineers are employed.

I personally think that the best thing to outsource if one can is QA.  Having a third party not involved in development to do QA is helpful and if you make their payment dependent upon the number of bugs/problems they find it usually helps get the product to a higher quality faster and cheaper.

Code Monkey
Wednesday, July 14, 2004

"I think as long you can clearly delineate the specs ..."

That's where the trouble lies.  In the added time to "clearly delineate the specs" you could have coded it yourself already.

NoName
Wednesday, July 14, 2004

Code Monkey is on target. I love the guy who says "in the time you took to specreq you could have coded it" ... oh yeah, this guy must be a manager.

me
Wednesday, July 14, 2004

The only proof a system is running correctly is the running code. Neither one of the analysis, design, coding and testing have any meaning without the code itself. Therefore they cannot be separated.

The architects, developers and QA must have the same strong understanding of the problem domain before they can build a solid, good quality software product.

IMO outsourcing software development is doomed to fail if it is based on the assumption that the 4 above mentioned functions could be separated.

Dino
Wednesday, July 14, 2004

"I think as long you can clearly delineate the specs, it shouldn't be much of a problem to outsource (offshore or not) the development of small portions of any given system."

If you do the specs to the required level of precision, you'd probably get more productivity out of *in-house* developers.

If managers just pretended that their in-house developers were on the other side of the planet, and exhibited more self-discipline, I think they'd find themselves getting a much higher return on their IT spending.

Instead, having the developers conveniently accessible probably leads managers to provide looser requirements definitions, make last-minute changes, and more complex requirements (rather than simpler requirements that will be easy to explain).

Jon Hendry
Friday, July 16, 2004

Code Monkey writes: "Come on.....majority of the projects especially in the corporate world are either maintenance of existing stuff or small incremental enhancements and hence the percentages do not hold.

What you say is true for new projects or major rewrites of existing projects  but that is not the bread and butter area in which many software engineers are employed."

The thing is, a project getting "small incremental enhancements" for a while can suddenly need a significant extension.

For example, maybe a bank has a trading system that's mature. The bank merges with another, and in the process a decision is made to move a significant chunk of functionality from the other bank into the mature trading system of the first.

Jon Hendry
Friday, July 16, 2004

*  Recent Topics

*  Fog Creek Home