LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

The Case for Boring Technology

3 min read Software Architecture
architecturephilosophydevelopmentpragmatism
Contents

Every few months, a new framework promises to revolutionize development. And every few months, teams adopt it, struggle with immature tooling, and eventually rewrite in something more established. There’s a better way.

The Innovation Token Budget

Dan McKinley’s concept of “innovation tokens” captures this well: every organization has a limited budget for adopting new, unproven technology. Spend them wisely.

You probably get three. Maybe.

If you’re using:

  • A new programming language
  • A new database
  • A new deployment platform
  • A new frontend framework
  • A novel architecture pattern

…you’ve already overspent. When something breaks—and it will—you won’t know if it’s your code, the framework, or an obscure interaction between your five bleeding-edge choices.

What “Boring” Actually Means

Boring doesn’t mean bad. It means:

  • Battle-tested: Bugs found and fixed over years
  • Well-documented: Stack Overflow answers exist
  • Understood failure modes: You know what breaks and how
  • Available expertise: You can hire people who know it
  • Stable APIs: Code written today works tomorrow

The Boring Stack

Layer Boring Choice Why
Language Python, Java, Go, C# Large ecosystems, known performance characteristics
Database PostgreSQL, MySQL Decades of optimization, tooling, knowledge
Cache Redis Simple, fast, well-understood
Queue RabbitMQ, Redis Proven reliability
Web Server nginx Handles almost everything
Frontend React, Vue Mature, large communities

The Hidden Costs of New Technology

Learning Curve

Your team needs to learn:

  • The technology itself
  • Its idioms and best practices
  • Its failure modes
  • How to debug it
  • How to operate it in production

This takes months, not days.

Missing Ecosystem

New tools lack:

  • Monitoring integrations
  • IDE support
  • CI/CD plugins
  • Security scanning
  • Migration tools

You’ll build these yourself or go without.

Documentation Gaps

Try debugging an obscure error in a framework released six months ago. The GitHub issues are your documentation now.

Hiring

“Must have 3+ years experience in [technology released 18 months ago]” is a job posting that stays open.

When to Use New Technology

New technology isn’t always wrong. Consider it when:

  1. It solves a problem nothing else can: Some problems genuinely need new approaches.

  2. The risk is contained: A new library for PDF generation is different from a new database.

  3. You can afford to be wrong: Side projects and experiments are great places to try new things.

  4. The technology has crossed a maturity threshold: “New” is relative. React in 2016 was risky; React in 2024 is boring.

A Decision Framework

Before adopting new technology, ask:

1. What specific problem does this solve?
2. Can a boring technology solve it adequately?
3. What's the cost if this technology fails or is abandoned?
4. Who on the team has production experience with it?
5. What's the size of the community and ecosystem?
6. How will we debug production issues at 3 AM?

If you can’t answer these confidently, reconsider.

Case Study: Database Choices

A startup needs a database. Options:

Option A: CockroachDB

  • Distributed, scalable SQL
  • Relatively new
  • Smaller community
  • Novel failure modes

Option B: PostgreSQL

  • Single-node to start
  • Decades of production use
  • Massive community
  • Well-understood scaling path (read replicas, then Citus if needed)

For 99% of startups, PostgreSQL is correct. You’re not Google. You don’t have Google’s problems. When you do, you’ll have Google’s resources to address them.

The Compound Effect

Boring technology compounds positively:

Year 1: Slower initial development, but fewer surprises Year 2: Team is productive, onboarding is fast Year 3: System is stable, easy to maintain Year 5: Still running, minimal changes needed

New technology often compounds negatively:

Year 1: Exciting! Fast prototyping! Year 2: Framework released breaking changes, major rewrite Year 3: Key maintainer left the project Year 5: Rewriting in something else

Practical Advice

  1. Default to boring: Make it the starting point, not something you have to justify.

  2. Contain experiments: Try new things in isolated services, not core infrastructure.

  3. Wait for 1.0: Let others find the sharp edges.

  4. Value operational simplicity: Running software is harder than writing it.

  5. Optimize for the long term: Most code is read and maintained, not written.

Conclusion

Choosing boring technology is a competitive advantage. While others chase the new hotness and deal with the consequences, you’re shipping features, sleeping well, and building on a stable foundation. Save your innovation tokens for your actual product—the thing that makes your business unique—not your tech stack.

Comments