Choose Boring Technology (2015)

> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. This is one of my favorite blog posts, and it can basically be encapsulated in the idea of "innovation tokens." It is one of the most useful concepts I have had as a PM / eng leader in my career. It helps actually make the the right tradeoffs, and helps even more in explaining those tradeoffs to colleague of all levels. Highly recommend.

This is a great article, I feel like I think of this a lot when I build something new. The tricky bit I think though, is deciding what actually is boring, since really we should factor complexity in too. I work a lot with data in python, for in memory data, the most popular choices are: - pandas - pyspark - polars Pandas is the most established, although has a lot of technical limitations, as well as complexities. Pyspark is definitely an "industry standard" choice, but now you're dealing with distributed computing when you probably didn't need too. Polars is the simplest in terms of API and not being distributed, but then is the newest. I can easily imagine a discussion where three engineers all agree that they should choose the "most boring" tech, but all choose a different option.

Golang was supposed to be boring by design (https://go.dev/talks/2012/splash.article) and you can use it in a boring way. Even learning golang is relatively boring.

In hindsight I disagree. Instead I like “only work on impossible problems” Most of them turn out to be impossible, but some of them turn out to be possible. I’ve never met anyone who could pick 3 and be confident in getting even one right. Tokens are a terrible analogy for innovation or research. In hindsight I’ve had to sift through hundreds or more to fine one that worked. I thought this post was helpful when I first started thinking about startups. After more time, I think boring tech isn’t worth thinking about.

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may think "New" means untested, but is that true? What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc? I should just say "Choose well tested" instead of "Choose old" - lots of old software is very poorly tested. Maybe I think that "Old" implies better documentation, but does it? Lots of older projects have insane cruft and weird edge cases that are undocumented and accumulated over years. Why do we need a metaphor? Why is "innovation token" helpful? If you're incapable of evaluating a technology in terms of these properties, you aren't a serious developer and "boring" will not save you. Sit down, write our your requirements, determine candidate solutions, and choose them based on their fit. "Boring" means nothing, it's a vague proxy term. "Well tsted", "performant for our use case", "developers know it", etc mean something. > MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring. Literally every one of these has caused hilarious and disastrous failures for me in my career. But yep, boring. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better? I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits.