Lately I’ve been digging into technology decision making and the notion of “boring technology”, inspired by Choose Boring Technology. I consider reading about Boring Technology as a penance for my impulsive tendencies earlier in my career.

Some of the technical directions I championed during that time were worthwhile. I think pushing Eclipse as a reasonable Java IDE as an early adopter many years ago was a good decision.

On the other hand, that new parser I wanted at one point, the one that seemed quicker but resulted in the parsing code getting rewritten because I missed that part of the cost, or the Nth bug tracking system that I promoted and implemented in one week because it would make our “productivity better” - I’m not sure if those actually moved the needle in the end.

With the benefit of this experience and a few years later, I’d like to use this article to explore costs, shiny objects and decisions.

It Costs More Than We Think

A thesis of Boring Technology is that we, as an industry, consistently under-estimate the long-term cost of changes and choices we make.

What do the costs really look like?

Cost #1 - Implementation Cost

The engineering team proposes a new technology. It’s new, seems like a trivial addition to the overall architecture and it’s contained to one use case for now. What will it cost to implement?

This cost is the easiest one to think about, and we always focus here. How long will it take? How many people? Let’s argue about estimation!

Most often, decisions are made to minimize this cost, and this cost only. When we discuss “the cost”, we tend to over-value this area in particular.

Yes, in a limited perspective and a vacuum, that awesome new tech can solve the problem. But we’re part of a wider system, regardless of how shiny the object is.

Cost #2 - Maintenance Cost

How hard will this be to fix in 2 years when it fails? How hard will it be to expand functionality in this area in a year?

As the number and complexity of technologies in the system increases, the work to maintain it and extend it also increases. This complexity also heightens the risk of something unexpected occurring later.

Work in this context is Maintenance Cost, and it scales as the number of technologies increase. Consider this before adding another technology to the stack.

I’ve talked to many senior engineers and architects and this same issue keeps coming up - how do we look after the code later? The reason that they’re asking this question is because these are the folks who are responsible for looking at the big picture and how it all fits together.

We forget to pass the knowledge on. No context, training or communication trail is left for archaeologists in the future. These activities are not “overhead”, they are specifically targeted at reducing this cost.

Cost #3 - Mastery Cost

With more technology choices, there is less probability that anyone in the organization spends enough time with a technology to actually master it.

One of the best books I read early in my career was The Pragmatic Programmer, and it’s in their subtitle - “Your Journey to Mastery”. It takes time to get good at something, and if we’re switching contexts every week, or every feature, no one can get truly good at anything.

Picture a restaurant. You look at the menu, and you see at least 6 or 7 distinct styles across a 15 page menu that you can barely lift. What would you think of that restaurant? You certainly wouldn’t assume that they were the best (or even good) at anything at all.

Missing deep expertise is an efficiency cost. The less expertise we have in the system, the less efficiently we can anticipate and deal with problems in the future, and the more costly it is when problems appear.

This cost is related to Maintenance Cost, and compounds as the knowledge and expertise for specific technologies slowly leave the organization over time. It’s more expensive to fix if no one can figure it out!

There are also indirect retention costs from this effect. There’s a straight line between mastery and intrinsic motivation. People that are on a journey to master a discipline or technology are people that will stay with you for longer as they walk that journey. We as leaders just have to make sure that we’re establishing an environment where this is possible, it’s better for business.

People that don’t have a clear path to mastery in a domain are more likely to leave, and this incurs even more cost as we are forced to replace them.

Change is constant, but still, don’t stop your teams from becoming experts by always changing the game.

How to make better decisions?

Decision-making with limited perspective is not specific to us in tech. For example, it’s especially problematic as we look at climate change and policy.

What practical steps can we take in our domain?

There are lots of frameworks around prioritizing and triage, like Eisenhower boxes, but we need to go deeper and add new structures and models to our thinking around decisions.

We need to think about who makes the decision and how we model the decision.

Start with this framework, and make use of other tools to understand the proper collaboration and thinking model to use.

While doing so, think about these types of cost and what the long-term impact to your organization will be.

Remember, decisions that ultimately cost less, and produce a lack of excitement - can, in some cases, cause boredom.

Sometimes that’s ok.

This Week’s Cornucopia of Links

• Up to 40% of folks are considering leaving their current jobs.
• I was getting re-acquainted with feature flags.
• Somewhat related to my LinkedIn post on June 14th on Yak Shaving (aka Moose Shearing), how to get yourself to do things.
• On Borbs and Floofs.
• Who were the Romans?
• The secret to winning at Risk using System Thinking.
• Words that unexpectedly share the same origin.