Not Invented Here Syndrome (NIH) is the guilty pleasure that tempts engineering teams into creating bespoke approaches to problems that have already been solved. Even having your eyes opened to the temptation doesn’t immunize you from it. So, how do you know whether a bespoke solution warrants the effort or if it’s just plain hubris?
When you’re trained to architect solutions to problems, the off-switch doesn’t always come naturally. It’s only one small step from looking at a software challenge or existing product to concluding: “That’s not the approach I would’ve taken. I could do better. And here’s how.” This insight is not necessarily bad on its own. However, when it becomes less of a thought experiment and more of an actual experiment — you’re paying an opportunity cost. Seemingly, only direct experience (seeing custom approaches succeed or fail) over time will stay your hand from succumbing to your own college try. Often the “senior” developer has to start rattling off the graveyard of abandoned frameworks, deprecated libraries, or scrapped internal projects that nearly every company has in order to remind you of the pragmatism of using what works.
We at Alley have our fair share of internal tools that we’ve created or reinvented, but we exercise restraint and feel strongly that these were pragmatic decisions. To wit: we’ve narrowly avoided recreating our own version of Jira, but we often consider it. So what does Alley consider pragmatic to build for ourselves, and why?
Hermes: Our intranet and middleware between several SaaS products
Yo dawg, I heard you like SaaS, so I put some SaaS in your SaaS.
This fell into the category of too helpful not to make and too custom to use a pre-existing tool. We use many products that have their own sources of data — Hubspot, Jira, BambooHR, Google Workspace, GitHub, and our chatbot — Alleybot, to name a few.
Hermes performs a multitude of functions for us and serves as a home base for many different processes. It’s a single interface that rolls up performance against Agile OKRs (we use Scrum at Alley) and forecasting, customized just the way we like it. It provides a self-service option for clients to see progress on certain projects. And so much more.
Like many in-house projects, it started as an excuse to learn a framework while solving a business need. From there, it was a short leap to internal dogfooding other use cases. While it might serve partially as a pressure release valve for the “change we want to see” (usually data visualization and collaboration) from our SaaS vendors, somewhere along the road, Hermes became indispensable.
Broadway: Our local development environment
I don’t always fork VVV, but when I do…
Alley’s local development environment (nicknamed Broadway) is our secret sauce for making amazing client projects. It probably has enough customization (particularly in its client package management systems) to justify its existence, but if we’re honest: it’s custom because, like our editor configurations or favored terminal client… we’re artists, it’s our palette, and it’s kinda personal.
Alleybot: Our heavily customized Hubot (Slackbot) for flair
“Must have taken forever to build.”
Kevin Rawley (Owen Wilson), Meet the Parents
“No, not too bad. About 70 hours. Which isn’t bad, considering I carved it all by hand from one piece of wood.”
Alleybot and its associated hijinks serve both our workflows and our culture. One piece of the functionality has been open-sourced for the good of humankind – an easy way to view and claim code review tasks in Slack — but most of Alleybot’s functionality (and snark) is geared toward our specific style of work, and we’d be ill-advised to share it without regard for other workflows. If you’re looking for a less opinionated version to share with the world, check out our Slack App Helperbot. For now, Alleybot only talks to us.
Open-Sourcing Internal Tools
All of the examples above are closed-source (private) repositories, but how do we decide what constitutes our secret recipe and what might be valuable to the greater community? What’s the difference between some of our “invented here” projects that are open-source (say Mantle or Fieldmanager) and the above? Well, for one thing, they managed to pass the following smell test, but for another: their application became so essential to various projects’ success that we knew others would find them useful.
Here are some questions that we ask ourselves to avoid succumbing to Not Invented Here Syndrome:
- Would the subjective benefits (fun, learning, community enrichment, marketing, etc.) outweigh the objective costs? What’s good for a hackathon may not be great for the bottom line. Don’t eliminate hackathons, but consider forcing projects to stand on their own for a bit. Time has a great way of proving viability.
- Is the approach not merely novel, but objectively better? Is it more efficient, more secure, provide core functionality, etc? Can you prove it? Work to document the “why” of your project.
- Can it fail? Who else has a solution to this problem? Can we use their tested model? What’s the backup plan? You’re currently living without your novel implementation, what happens if you are forced to continue doing so? Does the world need another react boilerplate?
- Are you thinking rationally about your supply chain, or merely looking for control or prestige? Draw a line in the sand for your supply chain or service inputs and outputs. Not every engineering shop needs their own container stack, custom CI/CD pipeline, hosting solution, cloud, lobbyists, etc.
- How does this fit into your business model, or can it upend it? View your solution through different perspectives. Would a consumer buy it? Would a competitor fork it? Would your staff actually use it? Does it make fiscal sense: can you produce a better product for less money to a greater audience? What’s the opportunity cost to your current mission, and are you as passionate about this as your current core competency?
Alley has several internal tools and utilities that we believe make us better at delivering our core services; experience has also allowed us to humbly resist rebuilding several mission-critical applications in the name of “doing it the right way.” We make light of it, but Not Invented Here Syndrome can be a real drag on the opportunity cost of your business’s mission. Reinventing the wheel can divert resources from projects that could dramatically improve life for you, your clients, and your users. Take the time to make sure you’re working on the right things!
If you ever need some advice on figuring out what you should be working on (or need help working on them) — reach out! We’re always here to chat.
P.S.: If reading this didn’t stay your hand, perhaps your business’s Hedgehog Concept isn’t what you thought it was. Maybe it’s time to break out that breadboard, install that new framework, fork that repository…. And PIVOT!
“They want to be the agents, not the victims, of history. They identify with God’s power and believe they are godlike. That is their basic madness.”
Philip K. Dick, The Man in the High Castle