Boring Technology

In tech, there’s a love of “boring technology”, the stuff that people know, and is fairly simple, so building upon the technology means that you won’t run into many roadblocks. In short, the known knowns are there and there are fewer unknown unknowns. I mainly agree with this sentiment – if you want to build something stable, you don’t want to be a bug tester for the underlying technology – you have your own bugs and features to build for your own application, let alone the stuff you build upon.

But, as with everything, it depends.

Nintendo is probably the biggest follower of this mantra – year after year they release consoles that use fairly old hardware. They’ve gone on record to say they like “withered technology”, since it’s easier for developers to understand (the hardware they use has generally been around for 5-10 years) and it forces the developers to create simpler games (so less turnaround on game development). Of course, there’s a trade-off – newer developers aren’t necessarily used to any one platform, so using an older technology offers less benefit, and some game studios wouldn’t want to build a game on weaker hardware – so they went to the other consoles, like Sega, Sony, and Microsoft.

One example of Nintendo’s love of withered technology – in 1989 they released the Gameboy – a small, hand-held device that let you play games on the go. The CPU Nintendo decided to put in each of these? A 4MHz Sharp LR35902. This chip was on par with other chips in the early 80s, so by the time production started picking up in the early 90s, Gameboys were shipping with 10 year old chips. Nearly 10 years later, in 1998, Nintendo released a successor called the Gameboy color, with the same chip, doubling the clock speed (8Mhz to run Gameboy color games).

The Gameboy was extremely successful.

But there are countless examples of not using boring technology to achieve success too. Amazon, in 1996, decided to change the operating system on all its data center servers from Solaris to a very unstable, barely 1.0 Linux. Back then, there were a multitude of Unixes, with few of them being open-source (and thus, requiring payment to a company in exchange for support). It was a gutsy choice, and not without its trials and tribulations, but fast-forward to today and I doubt many people use any other Unix than Linux server-side.

In the late 2000s, many small startups sprung up to compete in the SaaS market. Lots of them ended up using this “cool” and “new” framework called Ruby on Rails. Ruby on Rails released in 2005, and within a few years, many companies that would later become famous, like Shopify, Github, Twitter, and many more built their businesses on it. They could’ve chosen a boring technology like Java, or C#, or PHP, but they liked it enough to give it a shot. Plenty of companies these days find success using Ruby on Rails, and there are still a lot of developers for it.

So where does that leave us? I think using boring technology requires a few caveats. For one, boring technology is useful when you want to do something that’s been done before. If you use similar technologies to do a task that’s been done before, you’re probably not going to break the underlying technology.

But if you’re building something to last, it’s hard to stick to “boring technology” perpetually. You’ll always want to break backwards compatibility sometimes. It would be absurd to build your new app in Cobol (although you can), or something like RPG (every IBM computer since the 1960s can run your app, think about backwards compatibility!). You can only make good decisions, and revise them as you go.

One project that’s been around for a while, LLVM, had this to say about its code churn, from the Architecture of Open Source Applications:

Despite its success so far, there is still a lot left to be done, as well as the ever-present risk that LLVM will become less nimble and more calcified as it ages. While there is no magic answer to this problem, I hope that the continued exposure to new problem domains, a willingness to reevaluate previous decisions, and to redesign and throw away code will help. After all, the goal isn’t to be perfect, it is to keep getting better over time.

Predicting the future is a hard problem. If you could, you wouldn’t be reading this post – buy a lottery ticket and start sipping mimosas on the beach. You might choose some technology, built by some company, and learn that company went bankrupt. Boring technology is only boring at the moment, but it might become boring later on down the road – you just have to pick the winners before they win.

Take the story on choosing Ruby on Rails: in 2022, a comment on Hackernews about:

If you Think Github, Gitlab and Shopify are relevant, then yes. Ruby on Rails remains an excellent technical choice for mature products… Note that, just like any other tool it has pros and cons, one should analyze the system requirements and use whatever makes sense. I would however, dare say that it is a great fit for majority of businesses. Honestly, majority of frameworks out there today will get you 90% of the way: Rails, Laravel, Phoenix and Django just to name a few. As I get older, I tend to prefer boring tech myself..

In 2005, Ruby on Rails was considered exciting. 15 years later, it’s boring. Linux was exciting then, and hosting Solaris on the server-side today? Unheard of. You can’t choose boring technology. You can only choose the right choices for the time. Some choices work out, and some don’t.

Invest in psychics to see the future.