A meme of Ian Malcolm from Jurassic Park stating "You were so preoccupied with whether or not you could, you didn't stop to think if you should."
Image sourced from here

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 — then it gets tricky. Seemingly, only direct experience (seeing custom approaches succeed or fail) 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, Harvest, Jira, BambooHR, GSuite, 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 KPIs (we use Scrum at Alley), Harvest timers, 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.”
“No, not too bad. About 70 hours. Which isn’t bad, considering I carved it all by hand from one piece of wood.” 

Kevin Rawley (Owen Wilson), Meet the Parents

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. We’re considering a less opinionated version to share with the world (stay tuned), but, 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 Irving or Searchpress) 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 the 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. Case in point: Apple still uses AMD, Intel, and Qualcomm processors for most things. 
  • 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’ 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

The Latest news

01
02