How Not-Invented-Here Syndrome Affects Technical Direction

The bad news, and the wall every tech leader hits: No platform decisions are clear cut.

Investment capital, the processing power in our pockets, and a few generations of people steeped in technology have all made this software development thing complicated. Even the dusty corners of large applications have hefty requirements around accessibility, performance, responsiveness, and delight.

Despite a ramp up in complexity, many teams adopt the same starting mindset: We’ll build this feature out ourselves. This known psychological bias is usually referred to as not-invented-here syndrome. It’s an inherent distrust in external ideas or ability to execute — sure, someone else tackled it, but we could do better.

Labeled or not, every long-term software project involves decisions made with this not-invented-here bias in mind. Joel Spolsky’s classic article details a few benefits of keeping features in-house, especially as they relate to the Excel team at Microsoft.

At the same time, hefty feature requirements and the number of companies investing in developers has driven the open-source and software-as-a-service ecosystems forward. Like flat-packed furniture, these bits of prepackaged code may not be heirloom quality or match the exact aesthetic you’re going for, but they’re usable in a hurry.

Taking advantage of third-party code is easier than ever thanks to package managers and their ecosystems (like NPM, Yarn, Hex, and RubyGems, to name a few). Through their automated caretaking of dependency versions, environments, and sub-dependencies, it’s easy to forget just how much code comes from outside your organization.

So, with a feature request queued up, what’s the right approach?

Don’t “Roll Your Own”

It seems simple enough: Your developers are great, so you’ll take advantage of in-house talent to build the feature! Not much to argue against there. At least, until we start to list out to-dos:

• Build a team. Prioritize this effort and necessary funds over other potential tasks your team could be assigned to.
• Create a scope. What are the requirements for the first release and metrics for considering this effort complete? Who owns approval? Do decision makers have enough time to commit?
• Start the long-term roadmap. Since it’s an internal tool, how much time and money will be set aside for ongoing-and-forever future changes and improvements?
• Build a maintenance team. You likely don’t want your specialized A-team focusing on this forever, so you’ll also need documentation for hand-offs as team members and objectives change.
• Evangelize it across the company. Does your organization have other applications with a similar need? There’s a compelling argument that they should implement this solution too, which always requires extra considerations and inevitably brings a host of additional requirements.

That’s the short version, but it’s still reminiscent of If You Give a Mouse a Cookie. By opting to own the code, you also own the burden of planning and maintenance. For organizations with tapped development resources or no desire to plan the future of a non-critical feature, the responsibility is a nonstarter. What’s next?

Instead, Use Open-Source Software

As it turns out, other people (and companies) also have some pretty impressive talent, and their open-source contributions amount to a bunch of production-ready code.

Take data visualization. If you’re in need of a few interactive graphs, handling the trigonometry and visual output is onerous; joining the masses and using D3.js sounds like a good move. (Or one of the many libraries built on top of it, like Vega, Vega-Lite, and nivo.)

Crowdsourced bug reports, testing, security checks, and quality assurance are far more thorough than most companies can match (outside of the largest few). A high contributor count also increases the likelihood of current documentation, release notes, and a focus on regular updates. Often, an open-source library will even come with (free!) functionality beyond the initial need.

Open-source software also brings a pair of ease-of-use benefits along for the ride:

1. Your new hires may already be familiar. It’s easier to find a React developer than train a fresh developer on your in-house framework.
2. Installation, version control, and sub-dependency management are all streamlined through the use of package managers. Long-term software project maintenance will rely on keeping these libraries upgraded.

This all sounds pretty great. Is open source the answer?

Wait, Maybe Not Open Source Software

How confident are you in trusting critical business needs to volunteers? Over time, even popular open-source libraries wind up abandoned or fall off the pace of rapidly changing web standards.

Short of being a primary contributor, your company’s lack of a controlling financial stake is also a gamble. Outside code can change direction, goals, features, or become entirely abandoned without room to protest.

You’re also beholden to dangers like:

• Direction by committee (or everyone in a community).
• The coding standards of outside developers.
• Outdated, incomplete, or incorrect documentation.
• License choice. Can this be used commercially? Is attribution required? Will it require open sourcing all of your proprietary code if you use it?

There’s no shortage of horror stories from the past few years on the open-source + package management front: a copyright claim, a dependency of a dependency having malicious code, and even discord at the parent company.

If the open source approach is suspect, where can we turn?

Instead, Use Software as a Service

If you’re trying to integrate custom maps to your software, there’s a good chance you’ll become a customer of Mapbox. Some things, like satellite tiles and vector mapping, are beyond even the best open-source map providers.

Once you’ve committed to an outside company, they have a financial incentive to keep you satisfied with their service. In trying to stay out in front of open-source options, they often offer some combination of killer features, pristine documentation, or readily-available support. In certain situations, your patronage may even entitle you to feedback on the product roadmap or custom development.

Additionally, with a company-backed service, many potential open-source shortcomings become entitlements: Regular updates, roadmaps, code quality, and communication are assumed to be part of your subscription fee. And better still, there’s now someone else to point at if or when something goes wrong. It all sounds much safer.

Wait, Maybe Not Software as a Service

Nothing underlines the danger of third-party service reliance quite like Killed by Google. 

Even if the dependency is maintained by an industry leader, there’s nothing guaranteeing it’ll survive long term. Without a look at their books, you’ll never know if they’re stable or a startup floating on venture capital and an unsustainable business model. Acquisitions, acqui-hires, and pivots — these services are often backed by young companies still finding their footing, and there’s danger in how easily digital products can be sold or shut down.

If the service sticks around, you’re still reliant on an outside provider for a critical business need. What sort of price increase will you tolerate? Two costs loom in a replacement effort (pulling it out and creating a new one), and that gives the service a wide berth to adjust fees without losing customers.

Where does that leave us?

Roll Your Own Software Features

Control, direction, cost — a myriad of drawbacks await on the open-source and software as a service side of the fence, so we really should create everything in-house. The benefits speak for themselves:

• Uptime? You control where it’s hosted and any failover systems.
• Priorities and roadmap? Whatever you want, paired with your product’s future.
• License? By you, for you. You can even explore releasing it as open source for recognition or a paid service for future revenue.
• Maintenance and upgrades? As soon as you need them.

By creating and maintaining the code you need, all of the necessary features live on for as long as they’re required. Seems like a no-brainer.

A Merry-Go-Round of Logic

Those playing along at home probably noticed that we’ve looped back to the beginning. Like everything else in application development, the right path is it depends. Uncertainty kinda comes with the territory.

There’s no perfect answer, and the truth probably won’t surprise you: Most projects make use of all of the above.

Sorting Out Build vs. Buy

Not-invented-here syndrome isn’t the enemy it’s made out to be, but it also shouldn’t be the driver for your dependency approach. Software features are a true balancing act, hinging on everything from:

• Budget
• Timeline
• Future plans
• Developer availability
• Future plans
• Alternatives
• Future plans

And probably future plans, too. From inception to maintenance, every addition to your codebase will need to be weighed and measured.