Principle: Prefer boring technology

Teams adopt new technologies for excitement rather than necessity, creating operational complexity and knowledge silos.

Dan McKinley's 'Choose Boring Technology' framework:

Innovation tokens: Each team gets ~3. Spend them wisely.

• New database? That's a token.
• New language? That's a token.
• New deployment model? That's a token.
• Don't spend all tokens at once.

Boring technology advantages:

• Known failure modes
• Existing expertise (hiring, Stack Overflow, books)
• Battle-tested at scale
• Well-documented edge cases
• Mature tooling and monitoring

When new technology IS worth it:

• Boring option literally cannot solve the problem
• The new tech is the core differentiator
• You've genuinely evaluated the operational cost
• You have someone who's operated it in production before

Practical examples:

• PostgreSQL over CockroachDB (unless you truly need global distribution)
• Redis over custom in-memory cache
• REST over GraphQL (unless you have many diverse clients)
• Server-rendered HTML over SPA (unless you need offline/real-time)
• Cron jobs over event-driven (unless you need real-time processing)

The cost of a technology is not just learning it. It's operating it at 3 AM when it breaks.

The most common cause of outages isn't old technology - it's new technology that the team doesn't fully understand yet.

Making technology choices for new projects or features