The Boring Technology Checklist
Photo by GVZ 42 on Unsplash
Technologists love new technology—that new shiny thing. But, often, the promise of a new solution introduces new unforeseen problems creating unplanned challenges. Dan McKinley wrote"Choose Boring Technology" seven years ago, which admonishes exclusively chasing new technology and advises adopting battle-tested and proven technology. Choosing proven hardened and well-trod paths in technology is “boring” because the complete problem space is known, and mitigations for any trade-offs are well understood.
In their words:
What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad . You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
My favorite analogy for adopting new technology is how it is similar to adopting a kitten. Kittens are adorable and cuddly little creatures, of course, you want to adopt one. But now you need to care for the little fuzzy bum. Feed the kitten, play with the kitten, and change the litter. And regardless of you loving the kitten, sometimes it still turns into a couch shredding demon from the shadow realm that defecates in your beautiful garden. This is a frighteningly accurate analogy for the technology adoption lifecycle. The kitten will become a cat.
In a companion talk/website Dan proposes a system for selecting new technology called ‘Innovation Tokens’. You get three. One per technology. “These represent our limited capacity to do something creative, or weird, or hard. We really don’t have that many of these to allocate. Early on in a company’s life, we get like maybe three. Not too many more than that.”
Space Karen Fiat from boringtechnology.club
While creating fictional currencies is a super fun startup thing to do, lately we are permitted to apply more rigor to selecting new technology by adding some criteria for ‘boring and good enough’. This is a more systemic, reproducible, and desirable way to select technology. It doesn’t have to be a heavy weight process; a simple checklist will do.
What is boring and good enough?
A typical answer is: “it depends.” It depends on the unique context of the project itself. Your team and our shared experiences. While this context is essential, it is also a way to rationalize a particular technology choice** because you’ve always done it that way**. Not because that technology choice is objectively better but rather because it is familiar. Familiarity is a comforting and valid criteria, but it is not the only criteria worth examining as all technology will change and improve with time. But how do we define better objectively? What do we mean by boring?
In our opinion, Boring Technology is absolutely interesting; familiarity empowers the software developer to focus on unique problems instead of furiously iterating against previously unknown trade-offs. Working on challenging uniquely new problems is never dull or monotonous! If anything about a given technology is repetitive or tedious, it should be automated away.
The spirit of Boring Technology isn’t just about choosing familiar things. It is about technology maturity. Boring Technology is all about making conscious choices for stability, reliability, well-understood limits, and expected trade-offs. Cut through the noise of competing solutions by intentionally mapping to these criteria. Eliminating unknown-unknowns is what gives devs the freedom to focus on creating uniquely valuable software.
Familiarity, stability, reliability, well-understood limits, and expected trade-offs
Familiar technology is often good. It is even better if we have that technology in a production system today. Ramp-up, implementation execution, and roll-out are already well understood. Maybe the team became quickly familiar with something new by trialing it in an experimental hack side quest. Familiarity does not have to be something that was built a decade ago.
Stability is, quite literally, foundational. A stable foundation means more sustainable long-term maintainability. More adding features. Fewer fire drills filled with unplanned work. Ultimately we are looking for predictable releases and an easy-to-understand versioning scheme that biases for non-breaking changes. When changes happen, they are immediately available, documented in a living changelog. Ideally, the technology is open source or a managed service, backed by open-source. Even better, the project is openly governed with a public roadmap, issue tracking, and decision making all visible.
Reliability is tricky to measure. Reliable means we can trust the technology will do the job we expect it to, every single time. We can derive reliability from social proofs, but this measure is susceptible to bias. Internet reviews should be regarded with healthy suspicion! A better axis to evaluate reliability is identifying precisely what it is the technology does. Ideally, technology does one thing well. If the job is to cut through a thick jungle, you will find a machete is better than a Swiss Army knife. Reliable technology always does exactly what you expect it to do. Per UNIX Philosophy, it does one thing and does it well.
All technology systems have limits, and the best ones document precisely what the system quotas are. Well understood limits and trade-offs come from trustworthy documentation. The docs should also be accessible, up-to-date, and, if for a managed service, it contains explicit service quotas. While there should be no need to run rigorous benchmarks: anyone should be able to.
A Boring Technology Checklist
Below is a checklist to help you evaluate selecting technology for your next project. You don’t have to have a perfect score here to make a technology choice! This is intended to help bring some rigor to your decision-making process, but ultimately this is your kitten to adopt. Maybe it’s just too cute to ignore! Good luck with that.