Paved With Good Intentions
We’ve all done it. There’s an existing, battle-proven solution you’re considering for a new project. As ever, it’s not exactly what you need; maybe it only fits 80% of your use cases; maybe it lacks what you deem a must-have feature; perhaps you consider it bloated; at any rate, it’s not “perfect”. In your heart, you know that no one-size-fits-all product is ever going to fit everything to a tee, and so you opt to make your own — and with that, you’ve taken the first step down a perilous path.
As developers, makers, creators — whatever we call ourselves — we are drawn to the expressive power of our tools, so it’s natural that we want to build new and exciting things with them, but there’s a delicate balance to be struck.
I have frequently seen the decision to reinvent the wheel made with shockingly little consideration for the long-term implications. I’ve encountered individuals, and cultures in development shops, with strong Not Invented Here tendencies. Some of this is come by honestly — getting burned by a supposedly solid COTS product — but much of it seems to spring from a much more dogmatic place of Us vs. Them (“they” couldn’t possibly match our own engineering prowess). Sometimes (and I would say most frustratingly) it’s simple amusement: doing what the developer finds personally entertaining instead of what’s going to accomplish the task at hand most appropriately. Basically: they’re bored and this is the solution to their boredom.
By no means is this is a new topic, but I think it’s one we still fail to acknowledge and accord the proper consideration.
The Changing Development Landscape
As a youngster, when I was cutting my teeth writing GW-BASIC and eventually QuickBasic, the Internet as we think of it now did not exist. Communities like StackOverflow, GitHub, and even the ancient-relic-in-internet-time-scales SourceForge didn’t exist yet. The term “Open Source” had only just been coined, and while it was effectively happening, it was still a much more fringe, grass-roots endeavor. Linux was new, but it was more an academic exercise, not a platform that hosted the world’s infrastructure (and the majority of our telecommunications handsets). I eventually found a hub of QB enthusiasts on a mailing list (email too was a new fangled thing for consumers then), but collaboration and code reuse was not particularly common; we mainly showcased what we’d been building.
Now, we find ourselves overwhelmed by the sheer quantity (if not quality) of F/OSS. We work on projects with literally tens of thousands of upstream dependencies. Entire industries and businesses are built on top of systems and applications that are wholly developed by unaffiliated 3rd parties which give them away at no cost.
While the ultimate end of solving business problems has not changed that much, the means to that end is often radically different than it was 20+ years ago. Where once the majority of software was bespoke, much of it now is assembled from disparate pieces written by strangers you’ll never meet from countries you couldn’t immediately point to on a map. Certainly there is still custom development, but the scales have tipped toward leveraging what already exists for much of the development world. In a not-insignificant way, we often are writing glue layers, not full-blown software, as such.
Mind Your Own Business
One thing that has often baffled me in the decision to create custom solutions to already-solved problems is that otherwise-sensible deciders seem to completely forget what their core business is.
If yours is a product company, you focus on building your product for sale. If you’re a service company, you focus on the services you offer and your customers are largely unaware of what provides the service they consume. Obviously these are blurry distinctions and nothing is ever fully clear cut, but those are, broadly, where businesses land.
What is so perplexing is that I have seen many service companies pouring enormous amounts of time and energy (otherwise known as money) into building and supporting products that didn’t serve their bottom line. If you’re a service-oriented company and believe your hand-rolled solution is your differentiating value proposition over your competitors with COTS tooling, I think your internal marketing is possibly stronger than your engineering.
If you’re not actually selling that software, why on earth are you building and maintaining it?
The Long Tail
Now that you’ve elected to go down the path of adding yet-another-solution to the pile, what next?
Likely, you wound up here because a bright, capable developer has convinced you that this is the true path to enlightenment. I consider myself a middling programmer, but I’ve had the pleasure of working with many very smart people over the years, and I feel that I’ve gained a lot of technical insights from them. What I have found though, is that it is rare to encounter visionary technologists also endowed with business acumen. Sure, they exist, and they tend to be the ones who float to the top as successful founders, but in reality, they are exceedingly rare. The unicorns, if you will. And yet we find many sharp engineers empowered to make business decisions they’re largely unqualified to make.
While many new development efforts to “do it right this time” start out strong, it’s often because they’re first tackling the largest pain point in the Old World; plucking all that low hanging fruit. A previous solution failed to deliver in a way deemed critical, so the new approach solves that right from the start. Decent; we’ve fixed the problem, right? Well, maybe, but what is often lost along the way is all of the other things that the old solution did really well at and just stayed out of your way and weren’t pain points for you because someone else had previously invested considerable time and effort into making those dead simple and Just Work™. Now you need to put forth that same amount of engineering effort (and dollars) — to achieve parity.
Let’s say you get your new solution out the door. It works and it fixes the problems you previously had. Hooray, what now? Maybe it’s developing the next phase of functionality. Maybe it’s simply supporting things going forward as bugs inevitably crop up; and they will, because that’s the nature of software. So now, that 10-year-old proven solution you abandoned — the one which had 1,000+ fixed issues on GitHub and reems of documentation — is exactly the legacy you’re facing; the long tail of debugging you don’t even know needs to be done yet.
But, engineers are plentiful and you can hire talent to make it, right? Except your new hires, brilliant though they may be, are completely unfamiliar with your one-off solution. Absolutely, they can learn it, but that will take time. Stymying their efforts to get up to speed may be a variety of factors such as a lack of documentation (you are requiring your developers to write quality documentation so others needn’t peer too deeply into the black box, right?), “unimportant” decisions made early that locked you into patterns that are less than ideal, or maybe your efforts solved the big pain point, but you’re still working to get all of the other parts of the system commensurate with the old framework.
This, of course, assumes that you can attract the needed talent. No doubt there are some developers that relish the challenge of taming an unruly in-house system, but there are many that wouldn’t even look twice at those “opportunities”. While as an employer you’re not obliged to help your staff grow professionally, it’s a safe bet that 1) they will want to, and 2) your helping them do that will ultimately help you as well. Trying to entice a developer to come help with a system they’ve never seen before, and in all likelihood will never see at any future engagement, can be a tough sell. Obviously it’s not your job (or really even your desire) to prepare your staff for where they go next, but the environment you offer for them to mature in is absolutely a consideration they are making when thinking about working for you.
Yet Another Framework
So what’s the solution? How do we avoid the trap? Well, for one thing, despite my tone here, it’s not always a trap, and it’s not always something to be avoided, but rarely do I hear conversations about that before a decision is made.
If we’re not happy with how the current system works, what are the alternatives? This needn’t be an all or nothing approach. Maybe you can build off of that 80% solution that comes with batteries included — so your team doesn’t need to write their own session management logic, or database abstraction layers, or message queues. Maybe you can take some rugged, well tested large-scale modules and put them together in a way that makes sense. Maybe you can even contribute back to the community by publishing modules (with documentation and test coverage!) that will help others but don’t give away your revenue stream directly. Finding that balance is key, and requires some frank discussions of what the objectives are, what’s realistic, and what ultimately serves your organization’s goals. The important thing is having that conversation; really sitting down and having that talk.
And maybe, yes maybe, you are facing such a radically difficult engineering challenge that everything that came before is irrelevant. This happens, to be sure, but not everyone is facing the scalability challenges of Twitter or Facebook, so your engineering efforts may not need to mimic theirs.
Just Do It
So, after my railing against cooking up your own solution I’m now going to do an about face and tell you to go ahead and make your own. Take that kooky idea and build it. Think you know better than the big players? Create the disruptive new way forward. Dogfood it and make it better, but for God’s sake do not make your coworkers use it, and if you’re a decider, do not let these things just slip in the door without seriously considering the ramifications.
Every developer should reinvent the wheel, but not as a means of shipping software daily; as an educational effort. I have personally written HTTP, FTP, and SMTP clients and servers to better learn the protocols, the quirks of existing implementations, and what making those things actually work entails. I’ve written a few CMSes, and a custom templating language. I’ve written my own modules to do things that a half-dozen existing modules did (and which they did better — lesson learned). I’ve played in the guts of these things, to understand how they work, and I believe I am a better developer for it.
You will learn a tremendous amount solving an already-solved problem because you’ll have many reference implementations to compare to and likely a good understanding at the outset of how it should be. And, in all likelihood, while you are also learning all of the nitty gritty technical feats needed to make it work, you will hopefully take away that all important nugget: why you shouldn’t be doing this as a general approach.
