Editorial note: I originally wrote this post for the Telerik blog. You can check out the original here, at their site. While you’re there, take a look at their developer tools and controls offerings — they’re quite extensive.
If you ever want to set off a heated argument among software developers, you could do worse than to ask about “build vs buy.” This one touches the third rail to such an extent that it has many colloquial names attached to it.
If you want to see this debate in action, plenty of venues exist. Developers may accuse one another of reinventing the wheel, only to hear that some wheels need reinventing for various reasons. Opponents of the practice have even described it as a syndrome, called “not invented here syndrome.” But I have also seen proponents turn the tables and call out “not ever invented here syndrome” to describe software shops that awkwardly buy when building makes more sense.
Suffice it to say opinions abound and no clear consensus exists. The highly context-specific nature of a given example also muddies the waters. What makes sense for your team in your situation may not apply to another team.
I’ve offered thoughts on navigating this issue in another post. Today, I’d like to avoid controversy. I won’t weigh in on whether reinventing wheels makes sense because it deepens your knowledge or whether it wastes time and money. Instead, I’m just going to catalog the most frequent examples I see of wheel reinvention. As a consultant that specializes in assessing codebases and application portfolios, I see a lot of code. This gives me a bird’s eye view of what shops love to write themselves.