Re-Blog : The cost of reinventing the wheel
Since my blog content at my old company’s site seems to be selectively disappearing, I’m grabbing the content that I can and re-publishing here, before it all goes away. This was originally published on June 1st, 2009.
The reason for this rant? I see a shocking number of people objecting to buying off-the-shelf software because it is “cheaper” to build it themselves. An argument that boils down to a simple ratio: the value of your time compared to the complexity of the problem. Time is always money; “complexity” here includes both a fair assessment of the difficulties you’re likely to encounter, as well as whether or not the requirements are met by existing products. Being a database dork, one business problem where this argument bubbles up a lot is when someone needs a database schema comparison tool (back when I was a web page guy, the most prominent argument surrounded file upload controls). The question is typically along the lines of:
My predictable response includes the following:
- If you’re going to spend time on it, your budget isn’t really $0.
Your time is rarely free, and most likely never. Confirm this with those that approve and/or sign your paycheck. If that’s you, then I take this bullet point back.
- You will be learning from scratch.
You are going to painfully learn all of the nuances of the problem, which others before you have already encountered and (hopefully) solved. This is not exactly productive if the problem is complex. Sometimes this is the point, but that is far more common in academia than in business.
- You will have little to no support.
When you buy a product, your license almost always includes support from the vendor. Even without direct support (which can be fee-based or just slow), when you hit a roadblock with off-the-shelf software, access to peer-to-peer forums or even twitter can fill the gap, as other people using the product have probably come across similar issues. With your own code, who is going to help you work around bugs or figure out why it works a specific way? In that case, your support pipeline is your mirror.
Of course, there are plausible benefits to building the code yourself, some of which I’ve already alluded to:
- Your budget may really be $0.
Or put another way, you may be choosing between buying existing software and buying dinner tonight. If there is no approval for software expenditures, then that’s simply a reality. More on that below.
- Your requirements may not be met by existing products.
Let’s face it, not every need has been satisfied in the marketplace, which is why we see new products (and new features for existing products) cropping up all the time. I feel this way about bug/suggestion/issue tracking tools – I have not seen “the one” yet. We have used several, and while they are all lacking something (or many things), they are “good enough” because we do not have the time to invest in making that aspect better.
- You may really want to get your hands dirty.
In some cases, you want to learn the internals and enjoy the experience of solving the problem. This is okay if you are taking a computer class, or working on a leisurely project. But if you have an employer, this isn’t necessarily the best use of your time and the company’s money. (I can’t resist the temptation to ask, “Is it good for the company?“)
Except in the most extreme cases, if you have no budget because your employer says so, it should not be very difficult to justify the cost of the software to the bean-counters. This is in lieu of spending all those hours of your time not just solving the original problem but also dealing with all of the unforeseen issues that are inevitable … this costs them money as well, and prevents you from working on real problems that vendors can’t generically solve. In case you are having difficulties in this area, consider not demanding the most expensive version or even the big ticket vendors… there are other vendors out there that offer more affordable alternatives. This may come at the expense of reliability or feature set, but in a lot of cases will still suit your needs, at least in the short term.
For the specific problem I am talking about, here is a small sampling of products available that may prevent you from reinventing the wheel (including the “big ticket” guys):
Red Gate SQL Compare | ApexSQL Diff | Kentico Compare SQL | xSQL Object
SQL Delta | SQL Examiner | AdeptSQL Diff | StarInix Database Compare | SQLDBDiff
Simego SQL Admin Studio | Visual Studio Team Edition for Database Professionals
SQL Accord Community Edition | DbDiff (CodePlex) | Open DBDiff (CodePlex)
Berryware SQLMatcher | Embarcadero Change Manager | dbMaestro | IndusSoft WinSQL
Quest Change Director | DB Ghost | SQL Server Comparison Tool | DB SynchroComp
And no, this isn’t an advertisement for any of these guys, just a demonstration that the market does not always consist of just the one or two big guys you’ve already heard or read about, and that there is a product for almost any budget (some of these would pay for themselves after I’ve spent 30 minutes trying to reproduce their solution). There are “free” solutions also, such as manually generating the scripts from Management Studio and comparing them with a variety of file-comparison tools (including those that ship with products you might already have, like Visual Studio). But again “free” comes down to the difference between performing all of that work and clicking a button, and evaluating whether a “free” or “cheap” solution really fulfills all of your requirements correctly.
Every situation is different. You will have to weigh the pros and cons of writing your own code to solve a specific problem; just make sure you understand the domain and the range of alternatives, so you can determine how likely it is that “writing a quick app by Friday” won’t snowball into a 6-month project.
I learn and grow by spending time delving into the workings for a system.
When I have my developer hat on, I occasionally create tools that are not only useful to me, but potentially useful to others with similar needs.
Granted, not all of my work has a good return. Much effort can come to naught.
But still, the experience, skills, and wisdom can be golden (or at least bring some justification to apparently vain attempts). I may not be able to manually calculate the square root of a large number (electronic calculators are good for that), but knowing how it’s done can insightfully bring understanding and results to proportional tasks (i.e. divide to workable portions then combine to bring the result).
We all have different skills, and allowing everyone opportunities to develop their skills provides the stage for progress.
In opposition, we must also work within the boundaries of our organization. We have no excuse to play with ideas without meeting our obligations and timeline. Keep your objective in mind. Use the tools you have to meet your project needs first.
Be responsible to people and the needs arounds us, then we can solve the problem at hand.