🤓 "Boring" is just one strategy 🥱

🎵 The song for this post is I Wish I Knew How It Would Feel To Be Free, by Nina Simone. 🎵

One of the most-referenced articles in the Eng Blogiverse is Choose Boring Technology. Dan McKinley (who extensively quotes Kellan) uses the fantastic metaphor of your company having a limited number of "innovation tokens," so spending any of them to write your backend in Pony is probably a mistake. It'll make your engineers feel clever, but if you consider where their time should go, you probably don't want too much of it to go into looking into Pony's compiler code to learn why it's behaving weirdly when any other tech would have just worked. Another great read is Camille Fournier's "Make Boring Plans", which is a similar approach to operating and project management.

With all that said, I think we should challenge these from time to time. I sincerely like "boring": these are prudent approaches to risks many tech companies, especially in the late aughts, run into. My main challenge to this is that these are about risk management and avoiding the floor, rather than reaching for (or breaking) a ceiling. "Boring" is a good strategy if you think the bigger existential risk for your company is that Product & Engineering will flop around, enamored with their cleverness, and fail to ship a reliable product on a reliable schedule. But if you're more afraid of the business risks of shipping average product, at an average cadence, over the course of years, you should consider deviating, at least sometimes, from the playbook whose entire definition is "optimized for safety."

As a comparison, conventional wisdom in investing is "don't day trade, stick your money in index funds." I agree with this, and do this myself. But this approach, by definition, can't outperform the market. I think this is satisfactory for most individuals managing their wealth because for them, falling prey to losing too much money is a big risk, and they need a risk management strategy. But if you're a professional or sophisticated investor, I wonder how long you'll get to call yourself that performing exclusively "at market" for your whole career.

There are a few notable examples of weird tech being a part of a company's success:

• Most obvious is WhatsApp: they used Erlang, without containers, and manual deploys. They were able to keep the dev team to < 100 and had a $19b acquisition while servicing billions of users.

• While Fog Creek eventually killed off Wasabi, I think the case that it needed to exist to get them where they were is compelling.

• ITA, later acquired by Google, uses Common Lisp.

There are also examples of when it doesn't work out so well!

• Reddit was written in Common Lisp, then they re-wrote it in Python.

• Viaweb, the company Paul Graham got rich with and wrote all those Common Lisp essays about, was discovered by Yahoo! to be so unmaintainable by their other devs that they rewrote it in Perl.

Again, boring is frequently good, especially if you want to minimize the risk of downside. But if I hear a competitor is using Java microservices with REST endpoints and message queues with big React frontends, while I don't doubt they can hire bodies and deliver software, nor would I doubt they can beat us on sales or product direction or other businessey "make-or-break" ways, I'm also pretty sure I can form a team of way fewer devs (who are, admittedly, harder to find), give them more autonomy, and outrun them, both on delivering new features and the years of incremental changes. And we'd probably have more fun at work, too.

Okay, caveats: "Choose Boring" is also great advice because what I'm arguing here is very easy to fuck up, especially for people early in their careers. Picking weird tech does not, on its own, make you innovative, nor does it mean you will produce a better product. Most products don't need technical innovation of any kind, just plumbing. Atypical tech is not equally practical: betting on Scala is a better play than Gleam, for example. A well-executing team on a boring stack will outperform an average team on a more agile stack. And the hiring bit is real: most developers hate thinking about computers, actually, and those that you manage to hire may resent you for making them think about something that isn't Python or Java.