Selecting Unexciting Technology (2015)

By Dan McKinley Math, Programming, and Minority Reports | mcfunley.com Originally published: March 30th, 2015

One of the most pivotal moments in my professional growth was being managed by Kellan. By observing the long-term results of his technical strategy, I gained a perspective that fundamentally changed how I approach engineering.

Had Kellan not been so disciplined in "sticking the landing" regarding our technology stack, I wouldn't have had the mental bandwidth to become the engineer capable of writing Data Driven Products Now!

After a year away from Etsy, my passion for technology has returned, and my thoughts on this subject have finally crystallized. What follows is a summary of the "Kellan philosophy"—a distillation that I hope only mildly disturbs him.

---

The Concept of Innovation Tokens

Imagine your team has a limited budget of "innovation tokens." These are precious resources that you can spend however you like, but the total supply is strictly capped for the foreseeable future.

While you might earn a few more once your system reaches a high level of stability, most teams drastically overestimate their current balance.

How you spend your tokens:

• Choosing NodeJS for your website $\rightarrow$ -1 Token
• Opting for MongoDB $\rightarrow$ -1 Token
• Implementing service discovery tech that is less than a year old $\rightarrow$ -1 Token
• Writing your own custom database $\rightarrow$ $\text{Bankruptcy}$

Mathematically, your capacity for novelty can be viewed as: $\text{Remaining Tokens} = \text{Initial Budget} - \sum (\text{Novel Tech Choices})$

If you are a database company or a JavaScript consultancy, these expenditures are logical. However, most of us work for companies attempting to revolutionize global commerce or reinvent web payments. In that context, wasting your limited cognitive energy on innovating ssh is a recipe for failure.

---

Boring $\neq$ Bad

It is vital to understand that "boring" is not a synonym for "low quality."

Note: There is certainly technology that is both boring and bad.

However, there is a vast category of technology that is boring and good (or at least "good enough"). The primary advantage of boring technology is that its capabilities—and more importantly, its failure modes—are thoroughly documented and understood.

The Rumsfeld Matrix of Uncertainty

To quote Donald Rumsfeld, we must deal with two types of ignorance:

1. Known Unknowns: Issues we are aware of but haven't quantified.
   • Example: "We aren't sure how this database behaves when CPU hits 100%."
2. Unknown Unknowns: Issues we didn't even think to worry about.
   • Example: "We had no idea that writing statistics would trigger massive GC pauses."

While both exist in old tech, the volume of unknown unknowns in "shiny" new technology is exponentially higher.

---

The Systemic Perspective

Technology choices don't exist in a vacuum; they impact your entire organization and the resulting system architecture.

For instance, if a team already uses Ruby, introducing Python creates a complexity cost that usually outweighs any marginal benefit Python provides. Yet, when people discuss Python vs. Scala or MySQL vs. Redis, they often ignore all constraints and obsess over "the best tool for the job."

The "Best Tool" Fallacy

Your actual role is to map business requirements to software solutions. If software had no "baggage," you could simply pick the local optimum for every single problem.

The "baggage" consists of operations (monitoring, patching, scaling) and cognitive overhead (learning, context switching).

The hard truth: Your actual "job" is to keep the company solvent. Therefore, the "best" tool is the one that is the least worst across the widest array of your problems. Long-term maintenance costs almost always dwarf the initial convenience of the build phase.

Reductio ad absurdum: If we followed this to the extreme, we'd use Java for everything—including the frontend—just to minimize the stack.

---

A Process for Decision Making

Adding new technology is a decision with company-wide ramifications; therefore, it requires company-wide visibility. Whether your culture encourages this or allows developers to sneak in new queues and databases in secret, you must establish a culture of transparency.

The "No-New-Tech" Challenge

Before adding a new tool, ask: "How would I solve this problem without adding anything new to our stack?"

This exercise reveals two things:

1. Hidden Motives: It detects if the "problem" is actually just a developer's desire to play with a new toy (e.g., "I saw a cool webinar on graph databases, let's use one!").
2. Creative Limits: It proves how versatile a small, stable stack can be.

Evaluation Checklist:

• Does this solve a problem we cannot solve with current tools?
• Have we mapped the "unknown unknowns"?
• Is the operational overhead acceptable?
• Is this a "least worst" choice for the long term?

When people claim they can't achieve a goal with existing tools, the answer is rarely "it's impossible." Usually, the answer is: "Well, we could do it, but it would be too hard."

If you feel you've hit a wall, you probably just aren't thinking creatively enough.

---

Visual References