Boring tech is mature, not old

Original Article ↗ Hacker News Discussion ↗

Postgres and “boring” upgrades

  • One thread anchor is upgrading Postgres (v12→16) due to EOL: people like its predictability but say major upgrades still require careful planning.
  • Pain points mentioned: pg_upgrade wiping statistics (requiring ANALYZE and more downtime), planner behavior changes affecting query performance, and headaches when DBs live inside containers.
  • Advice: avoid exotic extensions, consider reindexing after some version jumps, benchmark performance before/after. SQLite is floated as a simpler, more “boring” alternative for some use cases.

What “boring” / mature tech means

  • Common definition: stable behavior, slow‑changing APIs, few surprises, lots of operational experience, good docs and community knowledge.
  • Boring tech lets teams focus on product and user problems instead of yak‑shaving infrastructure. Examples: Postgres, Java, .NET, C/C++, PHP/MySQL, Django, Rails, Go, Debian, shell tools, git/ssh.
  • Some note cryptography and infra (build systems, test infra) should be boring: predictable and invisible when working.
  • Others push back that “boring” is often just a label for “my preference” or “what makes me money,” and can be used to shut down trade‑off discussions.

Mature vs old vs dead projects

  • Distinction drawn between:
    • Mature: small change rate, responsive to issues, few surprises.
    • Old but unstable: upgrades break things, poor defaults, fragile abstractions.
    • Dead: no maintainer engagement, broken sites, missing downloads.
  • GitHub “last commit” is considered a poor standalone signal; better signals are: issue/PR responsiveness, security fixes, user reports, quality of open/closed issues.
  • Some wish software could “finish” and stop changing, but note that API churn, dependency incompatibilities, and security vulnerabilities force ongoing work.

Dependency, LTS, and ecosystem churn

  • Frustration with short “LTS” windows (.NET’s 36 months, similar patterns elsewhere) making stacks less boring than their branding implies.
  • Python’s dependency conflicts, native libs, and numeric stack are cited as especially fragile across machines. npm is seen as chaotic; some say Go and Rust are only boring if you pin/vendor carefully.
  • Others argue that languages whose effective package manager is “GitHub + curl | sh” are not mature in practice.

Career and organizational trade‑offs

  • Many praise boring tech for reliability and business value; infra choices rarely matter to customers compared to features and UX.
  • Counter‑argument: specializing only in legacy stacks (COBOL, etc.) can pigeonhole careers into low‑demand, lower‑paid niches. Balance stable tools in production with exploring newer tech on the side.
  • Several warn against resume‑driven greenfield rewrites with immature stacks; they often create long‑term wreckage. Incremental refactors and in‑place rewrites are favored when possible.

Old vs new and hype cycles

  • Repeated anecdotes of Kubernetes, complex microservices, and NoSQL deployments later replaced by a few VMs and Postgres, with big gains in cost and reliability.
  • Some are tired of blanket “K8s bad, VMs good” tropes, arguing Kubernetes can be a mature, boring solution when used sanely.
  • General consensus: neither “boring” nor “shiny” is inherently better. Evaluate stability, security, tooling, and team competence; adopt new tech selectively and with clear benefits.