On old Unix systems, backspace would show up as ^H. I couldn’t immediately find a way to strikethrough my title so I used ^H.
I find a lot of people who want to outsource their development oversees or to another company. There are clearly a lot of benefits to not having to worry about doing it or getting a better price. The benefits of outsourcing are readily apparent, so I’m going to focus on some of the times where outsourcing is not a good idea.
Programming is a knowledge acquisition activity, rather than a construction activity. People normally say “build” or “develop” software which incorrectly associates it with building a house. Constructive activities are easier to determine what needs to be done, how to fix what is broken, and how much progress has been made. Writing software is very frequently not this way.
Programming is more closely related to finding a cure for cancer. The primary outcome of research is to learn something, the research paper written at the end does not instantly put that knowledge into anyones head. No matter how well the research is done, or how well the paper is written, future researchers will not be able to continue where the original researcher has left off. This is because the next researcher has to spend a lot of time understanding what the paper means.
In programming knowledge is retained in the head of the programmer, the code is an artifact (or by-product) of that learning. While the artifact can be readily be transferred to another person, the knowledge cannot. Swapping programmers on a project is like swapping cancer researchers, it can be done, but most of the work is lost.
To put this in perspective for a business person. Suppose your company had outsourced a very complicated spreadsheet to do some forecasting. It has 200 tabs full of formulas and cross referencing, but the first tab contains all the results so no one ever really looks at anything else. Your company saved a bundle and produced something arguably better because it didn’t have the right talent at the time.
Your boss comes to you one day and says, here is this spreadsheet, about 10% of the time cell D46 shows and error instead of the correct answer. You know how to do spreadsheets, I need you to fix it before our presentation in 2 days. You should be able to do this easily because all of the work is already done, you just need to fix the bug.
You have created several spreadsheets this complicated before and so you aren’t immediately worried about fixing this one. Had you been working at the company earlier, you could have written this one. You spend a few hours backtracing the cells to find out how the values are being generated and find that it is really complicated. You aren’t really sure why a lot of those tabs exist and some of the formulas seem wrong. You wonder how this spreadsheet is producing any correct answers because it all seems wrong. However, you do know that the final answers seem to reflect the actual business. You decide you have three options:
- Spend a lot of time learning everything about this spreadsheet to fully understand it.
- Make some guesses about how things work and find a quick fix.
- Re-write the whole spreadsheet from scratch.
Time is running out and so you choose option 2, an attempt at a quick fix. After all, this is just one tiny bug and you have a time constraint. You spend a few more hours on it and change some things so that the error never shows up.
A few days after the presentation your boss comes in with another bug in the spreadsheet. You go with option 2 again. You silently wonder to yourself whether your quick fix created the bug. This process repeats a few more times and your boss starts to express concerns that you are not fixing bugs, you are just replacing one bug for another. You start to understand why some of those “extra” tabs are there and you realize that you broke the spreadsheet and that those tabs aren’t being used anymore because of your changes. Uh oh.
You realize option 1 (learn everything about the spreadsheet) is no longer viable because you broke things and don’t know how to put it back. Before you have a chance to think about re-writing it, you get moved to another project and someone else is now in charge of that mutilated spreadsheet. Which option do you think he will pick? I’ve seen people pick all 3 options, so whatever your pick is you have a 67% chance of being wrong 😉
This is a pretty good metaphor for what happens to code that is brought in from the outside. It’s also a pretty good metaphor for what happens when you move coders to different projects. After the code has had about 3 authors, the project usually needs to be scrapped and re-written. When I worked at Novell, my department boss decided it would be a good job to do a reorganization. Basically all of the coders and all of the projects were shuffled. The results were catastrophic, but I don’t think my department boss ever realized what he had done or why productivity plummeted.
Outsourcing definitely has its place, I’ve tried to provide some general rules to help you decide if you should outsource your next project.
Do Not Outsource When:
- You are a software company. Never outsource your core competency.
- You are writing complicated code. Even changing authors once can be expensive.
- You know you will need a lot of future changes.
- You don’t think you will be able keep outsourcing to the same person.
It May Be Okay To Outsource When:
- You know you will rewrite this code. For example a rapid prototype.
- The project is small.
- You are able to ensure that no future changes will need to be made. This means you can validate there are no bugs and you know you will require no new features.
- The project is not central to your core competency.
- Project is mainly displaying information to the user interface, very few algorithms are needed.
- The project is simple. For example, CRUD applications only Create, Read, Update, and Delete data from a database. This is built-in functionality for many programming frameworks. Be careful though, I don’t know how many projects start out as this and then eventually become monster-sized projects.
There are exceptions to all of these rules, but these are definitely good things to consider before picking an option.