I’m frequently asked for my opinion on outsourcing software projects and components and in the vast majority of cases I always end up explaining my distaste for outsourcing when you work in the software industry. It just doesn’t work very well at all.
People often decide that outsourcing could be a great idea for a specific project because they see an opportunity to bring something to market very quickly and don’t want to disrupt their existing development resource or interrupt on-going project work. Unfortunately, this decision is often based around the fundamental mistruth that “outsourcing, on a sufficiently small scale, is both cheap and quick and as such harmless.”
The train of thought that leads people to outsourcing is often derailed by a quick experiment in discovering what your company is really about and what your company really does. I have one rule:
“Never outsource your core competences or anything that leads to your competitive advantage”
It’s that simple. If you outsource something that gives your business a real competitive advantage, there is absolutely nothing to stop any or all of your competitors doing exactly the same thing. In this scenario, the only people that win are the agencies that produce the outsourced software.
I’ve mentioned this to people in the past who have been surprised by what they were about to do, and just hadn’t identified the product they were about to outsource as a competitive advantage. What this really highlighted to me was how people often struggle to identify what their company is really about and what their core competencies and products really are. Effectively what the “essence” of the company is and what the product really is.
A little experiment that I encourage people to do, is to take what you perceive your “core” product to be and then mentally remove everything else from your business in a “virtual outsourcing” thought experiment. Take what’s left, the nucleus of your product and look at it’s characteristics. Those characteristics are what your company is really about, and like it or not, if you attempt to outsource any of those core characteristics, you are deciding to side-line your own creative advantage.
This experiment is especially good at highlighting when a company's’ core asset is technology or a technology product, while they perceive themselves to be more of a media company or non-tech company. If your core product is technology, you are a technology company regardless of whether that’s what you set out to be. This often applies to online business’ who fail to grasp that if their product is a website, you can never take the technology away, and at it’s very core, that is the value proposition of their business.
Understanding your core competency is not the only place that outsourcing and software development fall apart, it just illustrates how businesses reach these conclusions in the first place. The original software outsourcing model was a natural evolution of the idea that software development process could be modelled after manufacturing in some sort of glorified “software assets” process where you built a bunch of components that just plugged together to make a system. This idea rode on the back of the general good practice of reuse in software development and the boom in “4GL” programmer-less languages in the 90s. Well, that fad never really worked out, but it took people awhile to realise that the core assumption that software is like manufacturing was fundamentally flawed.
“Software isn’t a manufacturing process, it’s a design process, and as such, should not be outsourced as if it were mass production or duplication”
Outsourcing the manufacture of plastic cups works really well. We all know what a cup looks like, and even if you make a particularly fancy cup, you’ll get your designers to come up with the patterns, you’ll ship your pattern to a manufacturing plant who specialise in duplicating plastics and you’ll ask them to make a few thousand. Which part of producing a few thousand of your plastic fancy cups was the important part? The design that you handed over that made your cup different to the others was the important part, not the duplication. Software works in exactly the same way.
When software was first offshored, there was this fundamental misunderstanding that the development of the software was akin to pressing CDs in a plant, or manufacturing a thousand cups, when actually it was more like when Apple make products “Designed in California”. They’re produced en mass in China, but that’s not the important part, the design is. Treating the design of your software as if it were replication will only ensure low quality of the resulting product.
If you’re attempting to outsource components of a bigger system, you’re also going to face a whole second set of problems all related to trying to make your outsourced components consistent and maintainable in the context of a greater software product. You’re likely to receive software that’s outside of any “house-style” in your code (with different conventions), the quality will be unmonitored and variable and you’ll find it very difficult to prescribe patterns, practices and QA processes. Once you’ve dealt with that collection of known unknowns, you’ll then have to integrate the outsource components into the system with nothing more than a contract in place to ensure that they work. Don’t let that contract fool you though, it’s not security, it just means you’re allowed to get mad when the software doesn’t work. You’re not going to get your wasted time back. Despite the best quotes and claims of third parties, never underestimate the effort of integration. I worked on a particular project which touted a “4 hour” integration process. All things considered, with 3 days of meetings and the trailing two weeks of implementation, it took roughly 300x the quoted length of time.
People are often driven to outsourcing as a way to circumvent resource restriction but all that happens when this is attempted is you fall foul of the traps highlighted by Fred Brooks in The Mythical Man-Month – namely, the communication overhead of coordinating outsourcing and your internal development and the effort that it requires vastly outweighs any perceived benefits of the outsourcing exercise to start with. This is all compounded by the fact that humans are notoriously bad at writing software specifications, and your best attempt at outsourcing is only as good as your best attempt at communicating your ideas in way that the other party thoroughly understands. But as soon as you specify succinctly, you loose any kind of adaptability and end up, in the best case, with the product you thought you needed at the start of the process, rather than the product you know you need by the end because of changing business requirements.
Rework in conjunction with outsourcing is difficult and costly and if you end up down that route, you’re going to want to avoid it at all costs, though, ironically, if the outsourcing venture is successful, you’re likely to want to bring the project in house anyway to curb high maintenance costs and loosing your competitive advantage. Maintaining outsourced software is expensive for a very obvious reason: agency culture dictates that they must charge an appropriate amount to offset their risk of having no work. Bringing outsourced or offshored projects back in house is going to cause you yet more problems, especially if your technology stack doesn’t exactly match that of the outsourcing partner. That great PHP system they wrote? Doesn’t work so well with your ASP.NET software or your Ruby on Rails app. You’re then faced with the horrible position of having to re-write to bring the software back in house, or maintain a whole separate set of systems to support this product, raising it’s total cost of ownership significantly. This might not be a problem if you make hybrid technology choices deliberately, but at this point they’re effectively forced upon you.
So is outsourcing ever a good idea? Well, probably not, all things considered. You’re more likely to get more consistent results by spending the money you’d allocated for that killer new outsourced project training your staff. In the long run it’s better value. It’s also sometimes more prudent to skip what you perceive to be that “killer opportunity” when you don’t have time or resource and revisit it later with a quality product that maintains your own creative vision and competitive advantage. There are a few well established large agencies with a known track record for delivery and professionalism. You’ll find these agencies are more likely to work alongside you and your staff, rather than dropping a boxed product on your lap, and this co-working gives them a distinct advantage over any other form of outsourcing as they are more likely to work well inside of your internal processes.
If you’re considering outsourcing a software project, you should always ensure that you factor the effort required to bring that project back in house as part of the estimate of cost. If you’re considering outsourcing part or all of your core product, you’ve probably already lost.