Making a hand-rolled solution to a common problem is a waste of time and resources. Sure, it's fun for us developers to build something to do X! But when X doesn't differentiate the company, it's a waste of time. I can understand wanting to build something new to solve a problem. I've felt that way myself in the past. And besides, it's what we do! But there's a time to build and a time to "buy." And, in the true fashion of being "lean and mean," it's best to optimize for NOT building. In this post, I hope to convince you to start looking at what's out there before building your own tool to solve a problem. Don't get me wrong; there are plenty of cases where it's best to develop a solution (we'll look at four good reasons). But it's better to use a battle-tested solution if one is available. You'll save time and energy and get to the real value quicker. I'll start by sharing a story about where I'm coming from.
Just Because You Want to Doesn't Mean You Should
Earlier in my career, I worked on a small development team in a somewhat large IT department. I naively thought that we should build almost everything in-house. For one thing, we used industry standard tools that had strange behaviors, clunky user interfaces, and archaic integrations. For another, we had a talented team of developers. We could have built some of the applications we were using to be even better. They would've integrated rather nicely with the platform of services we were already building. We could have spent all of our time building our own custom replacements for those tools. But when it came down to it, that wasn't the right thing to do for a few reasons. For one thing, we were focused on and committed to building solutions to problems that hadn't already been solved. We also had to ask ourselves if we could actually support more applications. Besides, the solutions we used were battle-tested. They'd been through the gamut of bugs and exception cases. Sure, we uncovered new ones frequently and had many workarounds in place. But the bottom line remained: carrying a lot of custom applications in your portfolio is expensive! If this disappoints you, I have good news for you! It's not always a bad idea to build your own solution. In fact, there are some good reasons to do just that.
When to Make Your Own Hand-Rolled Solution
Building a solution is a costly, error-prone, and risky endeavor. It has to be planned, paid for, and maintained. But there are certain advantages to doing so, especially when a solution pays for itself in time.
Strategic advantage. The number one reason to build your own solution is for strategic advantage (which is why it's #1 on this list, of course). Perhaps you have trade secrets to protect. Maybe you want to support a domain-specific process. Or perhaps you need a highly customizable solution. And last but certainly not least, perhaps you are creating a niche product to sell. In these cases, you'll want a solution that's just yours.
There's nothing on the market. When you've looked high and low and found nothing to suit your needs, you might be forced to build your own.
Market cost exceeds the budget and/or estimated cost. Let's face it: sometimes the market has solutions that offer way more than you need. Often, those solutions come with a high price tag. At times, it can be cost-effective to build the bits of functionality you need without all the bloat. In some circumstances, this is a good opportunity to profit on your byproducts (if you're into that sort of thing).
To have a little fun. There's value in letting people express themselves. Developers perform better when they are acting autonomously. Besides, many of the products we know and love come from free-time experiments. For example, Google's Gmail was a side project to create an internal email program. Sometimes, skunkworks projects become a hit! Even when they don't, they still allow developers to be creative.
There you go: there are some definite advantages to building a hand-rolled solution. But there are some hidden costs to consider. Let's look at those now.
The Hidden Costs of Rolling Your Own Solution
There are downsides to making your own solution to a problem of any size. Here are a few things to consider:
Unknown unknowns. There are things you won't know going into any software project. Those "unknown unknowns" are the biggest drivers of delays and defects. Unless you've controllered estimate jiu-jitsu, early estimates (those made during buy vs. build analysis) can't predict these kinds of overruns accurately.
Potential for wasting time. Wasting time on a hand-rolled solution could lead to higher costs and lost opportunities. If resources are fully committed to one project, you might have to hold back on other projects.
Potential for building the wrong thing/painting yourself into a corner. That would be a big waste. Don't do that! If you wind up building something that doesn't meet your needs, it may be time to focus on improving your team's technical skills.
If those risks outweigh the benefits, then you'll want to consider looking on the market for a solution to your problem.
When to Use Someone Else's Solution
Clearly, there are times when you'll use a solution that's ready to go. We developers do this all the time when we use platforms, IDEs, email, and the internet. Here are some guidelines for when you will want to select a ready-made solution.
Building in-house has no strategic advantage. If building an in-house solution won't differentiate your business within your market, it's not worth the effort.
You'd be using a common process. When you use a standard process like git-flow, pay the dough!
Too many variables make building expensive/risky. We all know software is hard. Any given project has nearly infinite variability. This makes it difficult to predict the costs. Businesses need to have a measurable risk in their investments. Hand-rolled solutions just aren't viable when the business isn't able to take on unknown risk.
When evaluating off-the-shelf solutions, you've got to weigh the options. Compare the expenses and be prepared to justify spending money on a ready-built and battle-tested solution.
Understanding the Risks of Using Someone Else's Solution
Even though buying a solution is the right choice in many circumstances, there are risks in buying a solution you should be aware of.
Hoodwinking. Watch out for those slickster salespeople, especially if they're highly motivated to close deals. To be honest, it isn't entirely their fault. Extrinsic motivation drives good people to do unscrupulous things. Be wary of sales tactics that are driven purely by commissions. Can they deliver what they sell?
Lack of information. Know what you're getting. If you're investing in a solution, make sure it fits your current and future needs. Let's face it: needs change, and the future is hard to predict.
Inflexible/slow to change. One problem that can come up is that the ready-made solution isn't flexible enough for your specific needs.
Expensive to customize. Even if the solution is customizable, those customizations can be costly! You might be wooed in by a low cost of entry and sold on the promise of customizations, only to find that those customizations come with a hefty price tag!
Unstable vendor/producer. Some companies aren't good for the long haul. They might drop off the face of the earth. Or perhaps their support is just...sort of...meh. Do your research before signing.
Unresponsive vendor/producer. Another problem that comes up is responsiveness to addressing issues. This can be a real problem if one of those issues is a critical blocker for you or creates a security hole.
Using some good old proactive risk assessment methodologies, consider which risks are significant to you before you go all in on a solution.
Conclusion
The business roles aren't the only ones making buy vs. build decisions. Often, deciding whether to build up a solution or buy one is an engineering decision, and it's one that you should make carefully. Do your research, because who knows—you could find what you need, like a feature you weren't aware of, in your existing components. The solution could be as simple as setting a certain configuration option (something I experienced today). Sure, we developers love to jump right into coding. But it can pay dividends to step away from the IDE and look for other options. Next time you are presented with a problem, take a step back. Pause and think to yourself, "Is this a common enough problem that there's already a good solution?" If the answer is "yes," then go out and look for that solution.