The Most Commonly Reinvented Wheels in Software
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.
If you have worked in the field for any length of time, you have doubtlessly worked on some application that spits out a log. For decades, a robust log file has served as a developer’s best friend for hunting down production problems. On top of that, you can use the log files for interesting usage analytics, security auditing, and painting a general, overall picture of runtime behavior.
As a result, almost every non-trivial application spits out some kind of log. And, as a result of that, logging technologies abound for any programming language and tech stack. You have an embarrassment of riches here, with well established, well maintained, and well documented options from which to choose.
And yet, this does not stop programmers from routinely rolling their own. Why? Well, I’d hazard a guess that reinventing this wheel tempts developers because of relative ease, in many cases. At least at first. I mean, you could go out and learn about how to use a popular logging framework, including configuring an XML file to specify an appender, and… ugh. Or, you can just add a one liner to write to a file.
Once you start down that route, each incremental change becomes easier with your homegrown solution than bringing in the big guns.
While I started with something very focused and universally applicable, I’ll switch now to something fragmented and specific. Software developers love to reinvent miscellaneous utilities.
Need to sort a list in reverse order? You can just copy and paste from Stackoverflow and have your own little utility in less than a minute. How about something that checks a date for validity or something that converts a string to an integer but never throws an exception? You can always find your own or write your own.
In this case, the ratio of implementation difficulty to search space sits on the low side. It might actually take longer to find the right framework library or third party tool containing the desired algorithm than to find or write the code for it. The result is millions of little implementations scattered across the coding universe.
The world has no shortage of database applications. The world also has no shortage of object oriented applications. Taken together, those two concerns create the need for object relational mapping to bridge the gap between those two dissimilar means of organizing data.
And we, as programmers, have been happy to oblige. For years, we wrote this tedious plumbing code over and over again. But eventually, common solutions emerged. Then, common solutions multiplied to the point where dozens of these exist for you to download and install.
But the duplication doesn’t stop there. In spite of the availability of mature solutions with tons of support, people still, in 2017, roll their own for various reasons.
File Format Transforms
Our penchant for reinventing wheels does not discriminate among persistence strategies. We do it for the database and we do it for files as well.
What do you do when you have the need to drop something to a CSV file? How about a JSON or XML file? Do you go to the package manager to browse for existing solutions? Or do you roll up your sleeves and start manipulating strings to produce the necessary output? How about when you need to read in such a file? Same thing?
I cannot tell you how many home rolled solutions I see for producing files with very common formats. I suspect that the reasoning here mirrors that with the language utilities.
Common UI Controls
Finally, I’ll conclude with what I see perhaps most commonly. People seem to love to write their own UI components for their application.
Don’t get me wrong. If it comes out of the box with the framework, such as ASP or WPF, they’ll use it. People don’t manually implement text boxes and submit buttons.
But if we move on to consider common controls not supplied with the framework, the game changes considerably. Do you need a grid, a calendar, or a date picker? Developers facing this need often seem to enjoy the challenge of building one themselves and supplying it to teammates.
I think this has similar motivations to file formats and utilities, but perhaps with a side helping of enjoying their craft. Building a user control means building a tangible thing that you can point to and put your name on. And isn’t that, at its core, why a lot of us get into this profession in the first place?
You might find yourself wondering I chose to write about this topic without courting any of the controversy. Why list common reinventions of the wheel without offering any counsel?
By way of answer, I’ll say that I cannot possibly hold forth on your specific situation. You have your own costs and benefits, your own goals and needs, and your own set of tradeoffs to navigate.
But I do think that awareness of which wheels tend to get reinvented the most will help you with your decision about what to do. With that awareness, you can say to yourself, “I’m on particularly fertile ground for reinventing a wheel, but does that really make sense for me here and now?”