Make versus Buy

Software development organizations routinely consider make versus buy decisions to determine if a software library, utility, tool, or application should be purchased from a third party or developed in-house. Many times these decisions are tainted because software developers sometimes like to develop their own versions of code rather than re-use existing code. This is a cultural issue that needs to be addressed rather than ignored. No development organization today can afford to build every last library and utility from scratch. Whether you are considering a math library for fast fourier transforms (FFTs), a configuration management utility, or an entire application, make versus buy decisions should be based on more than simply the cost of developing the application in-house versus the purchase price of the application.

Here are some other things to consider if you plan on buying software:

What training costs will be incurred before your staff can successfully utilize the software?
What quality and performance criteria does the software meet and are these up to the minimum standards of your organization?
How easily will the software integrate with your current environment and how much time and effort will be invested in writing conversion and translation tools?
How will maintenance of the purchased software be incorporated into your overall software maintenance plan?

On the flip side, here are additional criteria to consider if you plan on developing the software in-house:

Do you have adequate staff to complete the software without sacrificing ongoing development projects?
Is the software strategic to your business? If so, there are more likely to be intangible benefits such as developer experience that are gained by writing the code in-house. For instance, an organization developing scientific software may want to write their own FFT routine an organization specializing in business software may not.
Can you use this software on more than one project? Leveraging the development cost over several projects, versus paying multiple license fees, may impact a financial decision.
Do you have a separate budget for staff versus purchases? In many organizations, staff payrolls are part of preallocated budgets and software purchases are funded from different funds. As short-sighted as it seems, some organizations develop their own software package instead of purchasing one simply because they already have a budget assigned for development staff and financial controls prohibit them from spending that money on purchasing software.