Build vs Buy

This dilemma is one of the hardest problems in software.  The problem exists in many other spheres, but I think it’s worst in software because it’s so hard to understand the cost of either option at the time the choice has to be made. This is further complicated by the fact that those who are most qualified to make the the choice are almost exclusively biased toward one option or the other, making it very hard to have an objective opinion. As a programmer, I’m biased toward build.  For me building something always includes the added value of learning, something very important for the curious and creative sort of people who make good programmers. On the other side are technicians, operators and software vendors who typically prefer the “buy” option, either due to simplicity, deligated responsibility, perceived cost advantages or personal enrichment. Of course fear is another factor which affects both sides.  Programmers fear off-the-shelf solutions will limit their ability to work with the software or customize it to suit the application.  Others fear building software because the cost appears less clear, and an industrial mindset makes “reinventing the wheel” seem inefficient. In my experience it rarely makes a difference in terms of the metrics in which a software project success is typically measured.  I’ve seen no consistent difference in terms of overall cost, ability to deliver on-schedule or finished-product quality between the two choices.  These factors are more influenced by other aspects of the project. These aspects include the experience of the team, the methods of management, the balance of time/cost/quality and the overall satisfaction the people doing the work have with the direction chosen. There are of course many other factors, but the point is that the build vs buy decision is probably the least important component determining the success of the project.  That being the case, I promote the build option because the results are less likely to result in entanglements which result in hidden costs after the project is complete.  It also affords the team greater autonomy than the “but” option, along with the aforementioned benefit of making the people involved smarter.