More myths of software outsourcing
1. It will reduce costs, it's cheaper
It's most common excuse I hear, it's also typically the most short sighted, and most that likens software development to manufacturing widgets.
Firstly creating software isn't akin to producing widgets, it's a creative process that depends highly on communication, and the quality of that communication. I don't just mean spoken language there, as the issues with that are all but obvious, but cultural as well. The culture and approach of the company, as well as the work ethics of the teams must be the same, or there will be a lot of friction.
The speed that decisions can be made and acted on, are dependent one two things.
Firstly on how they decisions are actually made (i.e. process, hence why smaller teams with less management overhead and programmer lead projects will always beat the top down meeting driven interruption culture of bigger organisations). Though secondly and that which has more importance here is, the speed at which that decision can be captured, understood, written down (requirements, design, ticket etc), scheduled and communicated.
If you have an implementation team that is so far removed from that, it will be slower and the quality of the communication will be worse, clarification, updates and corrections will sap time, and time is very expensive.
Support - Once the system is built you're beholden to external costs for change and management of it. If you choose to bring it in house you do so with little or no implementation knowledge, so the learning curve for that will drive up costs massively as the internal team get up to speed.
Quality - The external team's main focus is making money, not making you a quality product, it has to be, it's a business equation. So negotiating for the best price (i.e. cheapest up front) is going to ensure high technical debt that will lower quality and drive up costs.
Ownership - There is a legal overhead for protecting your IP and possibly and company secrets (though if you're mad enough to outsource that ! ....... then well, you're likely not reading this).
2. Developers are all the same, it's all about numbers
The difference from bad or average system architects, designers, developers to good or great ones, is massive, I think that argument was proved a long time ago. The levels in productivity and quality are an order of magnitude higher from high quality developers.
As Michael Bean mentions :
"But writing innovative software cannot be done on an assembly line. It requires hard-to-find development and design skills. Farming out development to legions of programmers overseas will not create a differentiation advantage. When a technology company outsources software development, that company loses its capacity to innovate and its competitive advantage."
And never a truer word said I think, what is it that is trying to be achieved: creative & innovative software, or cheaper and faster widgets?
If you are (essentially)a software company, that being what you offer the customers is software, or a service that relies on software, then it's the core of what the business is. Viewing it with such laborious distance means you will most defiantly reap what you sow.
Creating good software & systems involves passion and creativity with a good healthy mix of "getting things done" attitude, out sourcing to a Dickensian sweatshop instantly removes all of these factors.
3. We'll bring it in house when it's done, and then look after it
I've worked on several clean up jobs and have walked away from several more because of this myth.
The reason the company changes it's mind and realizes that outsourcing is wrong, is because it goes badly, the relationship is sour and what is being produced is substandard and mediocre.
Typically because of a combination of the reasons mentioned above; poor communication and cost, over quality.
On the point of things going wrong ......... even if you have the best person in the world who's responsibility with in the company is to manage the development, their effectiveness is going to be massively reduced by having to deal with external teams.
They effectively turn into nothing more than a requirements channel and point of blame for the project, with little or no ability to influence proceedings.
I recently interview with a company and only learnt about this exact thing in the interview ....... I couldn't wait to get out of there ! I've learn't my lesson, trying to pull one of these projects out of the technical grave led to the experience and inspiration for the burnout post.
4. Can't find the staff, it's all the local markets fault, we have to do it
Would you open what you want to be a high quality restaurant with no chefs and then outsource everything in the kitchen to a remote fast food joint?
OK, the logistics are different but the analogy points out the lack of sanity in it all.
It's what a technology company does, and if out sources that it gives up the ability to control the quality and innovation at source.
On the point of "can't find the staff" ........ notice I'm not talking about physical location. I've nothing against remote working, personally I've done it for years. The original vBulletin team (that I was a part of) which built version 3.0 until 3.6, were remote working for the majority of the time. And the quality in that was very high (I'm proud to say), we weren't outsourced development, we were a part of the company.
You can build a virtual team and maintain high quality , this is 2010, the internet is the primary form of environment & communication for most of us in development. Just about all developers and designers I know prefer it.
Which is another blog post in itself, about mental health and social interaction!
37signals and Peopleware
are forever talking about methods of working, and how typical offices are actually bad for most creative software work (though they have their place).
5. We can use agile, get versions back quickly & keep track
Which within itself is no reason to outsource, if you really want to be "agile" then having the team as close to the feedback and decisions (i.e. a part of it), as possible is best, not the opposite !!
While you might see results sooner, you're still going to be plagued by all the above points.
6. When it goes wrong we can sort it out
When it goes wrong with outsource ............ it gets contractual, with an internal team it gets intense.
Though at least they are part of the company and the company is the people and technology. So in the later scenario the focus is to fix it and be successful, not to engage in the blame game and hiding behind contracts and quoting the effects of poor to each other.
Further reading :
Update : As per a comment by Michael Thore over at http://www.salient6.com, I'd agree with adapting the title to "offshoring" opposed to the generic and possibly misleading term of "outsourcing". But I still advocate having development as an integral & core part of the
business if and where possible. Ideally from the outset and definitely
in the long run.
It's most common excuse I hear, it's also typically the most short sighted, and most that likens software development to manufacturing widgets.
Firstly creating software isn't akin to producing widgets, it's a creative process that depends highly on communication, and the quality of that communication. I don't just mean spoken language there, as the issues with that are all but obvious, but cultural as well. The culture and approach of the company, as well as the work ethics of the teams must be the same, or there will be a lot of friction.
The speed that decisions can be made and acted on, are dependent one two things.
Firstly on how they decisions are actually made (i.e. process, hence why smaller teams with less management overhead and programmer lead projects will always beat the top down meeting driven interruption culture of bigger organisations). Though secondly and that which has more importance here is, the speed at which that decision can be captured, understood, written down (requirements, design, ticket etc), scheduled and communicated.
If you have an implementation team that is so far removed from that, it will be slower and the quality of the communication will be worse, clarification, updates and corrections will sap time, and time is very expensive.
Support - Once the system is built you're beholden to external costs for change and management of it. If you choose to bring it in house you do so with little or no implementation knowledge, so the learning curve for that will drive up costs massively as the internal team get up to speed.
Quality - The external team's main focus is making money, not making you a quality product, it has to be, it's a business equation. So negotiating for the best price (i.e. cheapest up front) is going to ensure high technical debt that will lower quality and drive up costs.
Ownership - There is a legal overhead for protecting your IP and possibly and company secrets (though if you're mad enough to outsource that ! ....... then well, you're likely not reading this).
2. Developers are all the same, it's all about numbers
The difference from bad or average system architects, designers, developers to good or great ones, is massive, I think that argument was proved a long time ago. The levels in productivity and quality are an order of magnitude higher from high quality developers.
As Michael Bean mentions :
"But writing innovative software cannot be done on an assembly line. It requires hard-to-find development and design skills. Farming out development to legions of programmers overseas will not create a differentiation advantage. When a technology company outsources software development, that company loses its capacity to innovate and its competitive advantage."
And never a truer word said I think, what is it that is trying to be achieved: creative & innovative software, or cheaper and faster widgets?
If you are (essentially)a software company, that being what you offer the customers is software, or a service that relies on software, then it's the core of what the business is. Viewing it with such laborious distance means you will most defiantly reap what you sow.
Creating good software & systems involves passion and creativity with a good healthy mix of "getting things done" attitude, out sourcing to a Dickensian sweatshop instantly removes all of these factors.
3. We'll bring it in house when it's done, and then look after it
I've worked on several clean up jobs and have walked away from several more because of this myth.
The reason the company changes it's mind and realizes that outsourcing is wrong, is because it goes badly, the relationship is sour and what is being produced is substandard and mediocre.
Typically because of a combination of the reasons mentioned above; poor communication and cost, over quality.
On the point of things going wrong ......... even if you have the best person in the world who's responsibility with in the company is to manage the development, their effectiveness is going to be massively reduced by having to deal with external teams.
They effectively turn into nothing more than a requirements channel and point of blame for the project, with little or no ability to influence proceedings.
I recently interview with a company and only learnt about this exact thing in the interview ....... I couldn't wait to get out of there ! I've learn't my lesson, trying to pull one of these projects out of the technical grave led to the experience and inspiration for the burnout post.
4. Can't find the staff, it's all the local markets fault, we have to do it
Would you open what you want to be a high quality restaurant with no chefs and then outsource everything in the kitchen to a remote fast food joint?
OK, the logistics are different but the analogy points out the lack of sanity in it all.
It's what a technology company does, and if out sources that it gives up the ability to control the quality and innovation at source.
On the point of "can't find the staff" ........ notice I'm not talking about physical location. I've nothing against remote working, personally I've done it for years. The original vBulletin team (that I was a part of) which built version 3.0 until 3.6, were remote working for the majority of the time. And the quality in that was very high (I'm proud to say), we weren't outsourced development, we were a part of the company.
You can build a virtual team and maintain high quality , this is 2010, the internet is the primary form of environment & communication for most of us in development. Just about all developers and designers I know prefer it.
Which is another blog post in itself, about mental health and social interaction!
37signals and Peopleware
are forever talking about methods of working, and how typical offices are actually bad for most creative software work (though they have their place).5. We can use agile, get versions back quickly & keep track
Which within itself is no reason to outsource, if you really want to be "agile" then having the team as close to the feedback and decisions (i.e. a part of it), as possible is best, not the opposite !!
While you might see results sooner, you're still going to be plagued by all the above points.
6. When it goes wrong we can sort it out
When it goes wrong with outsource ............ it gets contractual, with an internal team it gets intense.
Though at least they are part of the company and the company is the people and technology. So in the later scenario the focus is to fix it and be successful, not to engage in the blame game and hiding behind contracts and quoting the effects of poor to each other.
Further reading :
- Anita Wotiz - Outsourcing Software Development – a bad idea? (lots of follow up posts)
- Passion Computing - Disadvantages of Indian Outsourcing (more personal experience)
- avanicimcon - Risks in Outsourcing Software Development ( 4 great points)
Update : As per a comment by Michael Thore over at http://www.salient6.com, I'd agree with adapting the title to "offshoring" opposed to the generic and possibly misleading term of "outsourcing". But I still advocate having development as an integral & core part of the
business if and where possible. Ideally from the outset and definitely
in the long run.
It's cheap.... two years it's done..... hahahaah...
ReplyDeleteIndeed, two things it is not ! Cheap in the long run OR quick !
ReplyDeleteIf this were a post on "offshoring" rather than a catch all "outsourcing", I would agree with most of your points.
ReplyDeletecost - if you have a market opportunity and not the staff to develop, you aren't likely to hire an effective staff quickly enough. IF there is no time sensitivity, then do you really have a market?
devs - if you are a product company that's been in business long enough for your product to get stale(ish), so has your staff. you can't completely turn over your dev staff because they are maintaining the old but may not be capable of developing the new. IF there was a product outsourcing company that would build the product WHILE pairing with and furthering the capabilities of your current staff, you get the best of both worlds. a first rate product and a staff that can maintain it.
again "outsourcing" is too big a bucket. i don't think these points fit neatly but would argue "offshoring" instead.
*disclaimer* i am the vice president of a product devlopment company in Seattle. we develop products that our customers either take to market or use to solve internal challenges. we often partner and integrate with their development staff to make sure they can handle maintainance or enhancements.
Michael, for the most part I think I agree, I've updated the title and added a intro.
ReplyDeleteAs for time, again I agree. Time, and more importantly time to market is something I skim over or practically ignore. A lot of people I've talked to and worked with told me they “off-shored” because they had no people, and had to execute yesterday.
Maybe I should be advocating a hierarchy of approach. Internal or virtual → out sourced → off shored.