There’s a persistent bias in engineering culture toward novelty. New frameworks, new databases, new paradigms. But in production systems, boring is a feature.
Innovation Tokens
Dan McKinley’s concept of “innovation tokens” remains one of the most practical heuristics in system design. Every team has a limited budget for new technology — spend it wisely. This is the logic behind the Schema Evolution Engine: PostgreSQL, Alembic, and a validation registry. Nothing exotic. Nothing that fails in ways nobody has documented yet. The same logic extends to operational infrastructure — the Workflow Automation Framework uses dependency graphs and structured audit logging, not because they are exciting, but because they eliminate the category of failures that excitement produces.
Choose boring technology until the constraints force you to choose otherwise.
The Hidden Cost of New
Every new technology introduces unknown failure modes. PostgreSQL’s failure modes are well-documented after decades. Your new distributed database’s are not. When I migrated KalmSkills from JSON file storage to PostgreSQL, query time dropped from 12 seconds to 80 milliseconds — not because PostgreSQL is innovative, but because it is mature enough to make the hard problems invisible.
The companion piece to this argument — applied to automation specifically — is The Case for Boring Automation. Same principle, different surface area: when the tool disappears, the work begins. And the constraint principle extends beyond code into how I work with AI tools themselves — token limits as a forcing function for clarity, explored in On Finite Tokens and Infinite Tasks.
Related
Projects: Schema Evolution Engine · KalmSkills · Real-Time Analytics Pipeline · Workflow Automation Framework
Writing: The Case for Boring Automation · On Architecture as a Design Discipline · On Finite Tokens and Infinite Tasks
