by Jay Johansen | Mar 11, 2009
The company needs a piece of software to solve some business problem. Al says that they could write a program to do the necessary job. Bob replies that there are products available on the market to do this and rather than write a program themselves they should buy an existing product, or download something available for free. Al says a product they built themselves would better meet their needs. Bob says there's no point writing a program themselves when they can use something written by someone else. And then Bob will give his slam-dunk argument: "Let's not re-invent the wheel!"
This argument is supposed to end the debate. Why in the world should we re-invent something that's already been invented? That's just a waste of time, money, and effort.
But a little thought will show that the "wheel" analogy doesn't prove what those who use it think it proves.
Consider real life wheels. Do all the companies in the world who make wheeled vehicles -- automobiles, bicycles, lawn mowers, whatever -- all get their wheels from the same source and use exactly the same design? We need only look around to see that the answer is a clear "No". The wheels on a bicycle are not the same as the wheels on a motorcycle. The wheels on a child's toy car are not the same as the wheels on large earth-moving equipment. Indeed, the wheels on a small compact car are not the same as the wheels on a large luxury car.
Are the people who make huge earth-moving equipment idiots for making their own wheels for these vehicles, rather than just buying wheels from bicycle manufacturers? Aren't they "re-inventing the wheel"?
Of course not. There is a difference between "re-inventing the wheel" and "engineering a wheel to meet our specific requirements". If my application is different from yours, then maybe your wheels won't work for me.
Even if my requirements are exactly the same as yours, if I really would use exactly the same sort of wheel that you do, it doesn't necessarily follow that the smart thing for me to do is to buy my wheels from you. Companies make this decision with all sorts of parts all the time. It's called "make or buy". Whether we should make some part ourselves or buy it from an outside supplier depends on many factors: Do we have the tools and equipment to make it? Do our employees have the skills? What quantities would we produce? Etc. Ultimately it comes down to, How much does it cost to make it ourselves? versus, How much does it cost to buy it from someone else?
So returning from the wheel analogy to software: What are the relative advantages of make versus buy on software?
General advantages of buying: You can get it faster. The up front cost is usually less. Someone else will worry about maintaining and updating it.
General advantages of writing it yourself: It can meet your exact requirements. You control it. You're not dependent on anyone else to keep it working and up to date.
Which will work out better depends on the details of your specific situation. If your requirements are very similar to what many other people need, and if the effort to write a program to solve them is large, you should probably buy something off the shelf. If your requirements are unusual and the effort to meet them is relatively small, you are probably better to write it yourself.
At the one extreme, if I need a database engine, I would almost surely not write one myself, I'll just buy one. It would take years of effort to write a complete database management system, and I can download some excellent ones for free or for modest cost. I would have to have very specialized requirements or some truly brilliant and innovative new idea for it to be worth the effort to build my own. At the other extreme, if I need to add two numbers together, I'm not going to search the Internet for programs that do this. I'll just write the one line of code.
I think managers responsible for such decisions these days tend to be overly biased toward buying. But I have occasionally found myself on the opposite side of the fence, arguing for buying something rather than writing it ourselves. I used to work for an organization that refused to use any open source code because, they said, they were afraid that it would not meet their quality and security standards, and there was no assurance that the writers would maintain it. All of which is true in general, of course, but not necessarily true of any given product. Yes, there's a lot of junk out there, but no one is saying we have to pick a product at random, we can consider quality when we choose a product.
People who opt quickly for "buy" often fail to consider the total life-cycle costs. They think, It will take one of our programmers two weeks to write a program to meet this need, and that time costs me, say, $2000. I can buy a product to do it for $100. Buying is obviously more cost-effective.
But is it really? For starters, you're making the assumption that buying will use up zero hours of your staff's time. That is obviously not true. Someone will have to go through the process of searching for available products and making the selection. Once you get it, someone will have to figure out how to install and use it. That may be trivial: the product may have a simple install program and the user interface may be simple and intuitive. But often this is not the case. Often figuring out how a product works, what options or configuration parameters to use, and how to use if effectively, require considerable effort.
If the product you acquired turns out to not meet your needs, what then? Do you write off the purchase price as a nice try and go through the whole selection process again? In some organizations, there's a lot of pressure to not admit that a purchase was a mistake, so once you've bought something, you're stuck with it for years. Others fully expect to buy three or four products, evaluate them all, and then pick the one that is best for them. While this is more realistic, it means that you have to go through the effort of acquiring, installing, learning, and evaluating three or four times. If you can do this in just a week or two for each product, then evaluating three or four is going to take one to two months.
Unless the problem is very generic, it is likely that anything you buy will not do exactly what you want. It is the solution for somebody else's organization, not for yours. A product you build yourself will presumably be tailored to exactly your requirements. The custom product will enable your people to work more efficiently. How much is that worth in the long term? If ten people will be using this product and making your own will save each of them just one hour per week, then an initial investment in writing it of 120 hours will be paid back in just 12 weeks.
Many of the touted advantages of buying evaporate under careful consideration. For example, I often hear advocates of buying say that if we write something ourselves, we'll have to deal with testing and debugging it and working out all the kinds, while if we get a commercial product, someone else will have done all that for us. Well, theoretically. But a commercial product is unlikely to be bug-free. If a product you built yourself turns out to have bugs, you can fix them. If a product you got from someone else has bugs, what now? You can call the manufacturer and complain, and maybe they'll fix it and maybe they won't. Putting the burden on someone else relieves you of the direct cost of doing it yourself, of course. But it also means that you give up control.
Another common one is that a product you buy will likely have many more features than one you make yourselves. But this is a mixed blessing. Sure, it may have features that are "nice to haves", things that we couldn't justify building ourselves but can make good use of given that they came with the package deal. But every feature that is included that we don't need is potentially dead weight. I'm continually annoyed by features in Microsoft Word that I don't want but that insist on turning themselves on, like automatic formatting. Every extra feature brings with it the possibility of more bugs. And it means that effort was devoted to things that are at best irrelevant to us. I've been wrestling recently with a scheduling package that has all sorts of way cool features that we have no use for, but that has bugs in the features that we do need. If we had written our own, we would have concentrated on what we needed and made that work cleanly and well.
Again, let me emphasize that I am not saying that "make" is always the right decision. Far from it.
In general I think there are two key factors to consider: size and uniqueness.
When a project is small, it is likely that the cost of selecting an outside product will be greater than the cost of producing it ourselves. As the project gets bigger, the reverse is true.
I think one good rule of thumb is: If you can write the software to do what you need with a few weeks effort, just do it. You'll spend more time searching for the right product than it will take to write it. After that, buying becomes a more serious option.
When our requirements are unusual or very specialized, it is likely that there won't be anything available that meets them. When our requirements are just like everybody else's, then usually someone else has already solved them. I would be very unlikely to write my own word processing program, because this is a very generic requirement. Many people have a basic need to be able to type in text, format it neatly, and print it out. So many people need such products that many, many variations are routinely built in: writing with various alphabets, including illustrations, putting text in tables, etc etc.
Second rule of thumb: If your requirements are generic, buy. The more specific your requirements, the more you should consider making.
© 2009 by Jay Johansen