Rewrite or Patch? Build or Buy?

These decisions are ever present when constructing larger software projects. Do you keep patching and maintaining a legacy piece of software, or do you throw it out and start over? Do you buy somebody else's code and integrate it, or do you build it yourself?

The perceived wisdom is:

• Throwing out and starting over is high risk
• Building yourself is high risk

... and there is good logic behind the perceived wisdom, as in both cases you are essentially declining the input of other folks who came along before you.

Your problem is that you have no way to gauge the value of that input, and that is usually because you only have superficial insight to the problem domain.

One way to deepen your insight is to go and attempt to build it yourself. The goal of that exercise is mainly to educate yourself and gain a better understanding of the problems faced by the original creators of the legacy piece of software or of the third party library.

You go about this expecting to stop and throw your own work away once you gained enough knowledge to better understand the other products, and make a good choice. Most of the time, you will end up patching and buying, but it may very well be that your work does turn out best. More often than not, the perceived difficulty of a problem fades away, and in those cases a simple custom piece will perform better than some general purpose third party tool - but you'll only know if you try.

So don't be afraid to go and build, but don't get enamored by  your work. Be honest with yourself and always compare your work with the third party work, and observe how your evaluation changes as you slowly remove obstacles and gain new insights.

All too often, people will shortcut this and buy third party software blindly - and end up disappointed and frustrated.