Mike McFunley

> It turned out that they [The Guardian] were burnt, and wrote about their painful migration to a RDBMS and to safety

It's not really fair to judge technical decisions retroactively.

PostgreSQL in 2012 wasn't the same as in 2018. PostgreSQL was uncommon back then, there was a limited talent pool, it was painful to operate/failover/scale/shard, and it wasn't yet available on RDS. JSONB support only arrived to Postgres in Dec/2014.

The alternatives (e.g. MySQL) were also problematic, e.g. locking tables every time a new column was added was likely a deal-breaker.

They only migrated to PostgreSQL because they didn't want the pain and downtime of self-hosting MongoDB, but there didn't seem to be any major architectural issues. In this case it seemed like specific issues with MongoDB in production rather than NoSQL in general.

He briefly touches on the downsides during the talk, but the purpose of a talk is to excite and pique somebody's interest.

https://youtu.be/qI_g07C_Q5I?t=3120

In the book he uses more nuanced language and warns that it's not something to be used on every occasion.

* "It’s essential to test your expectations about programmer productivity and/or performance before committing to using a NoSQL technology."

* "Most applications, particularly nonstrategic ones, should stick with relational technology—at
least until the NoSQL ecosystem becomes more mature."

* "But we also realize that there are many cases, indeed the
majority of cases, where you’re…

I really love how Dan McKinley frames this kind of thing in terms of each company having a budget of "innovation tokens".

http://mcfunley.com/choose-boring-technology

edit: now it's a club! http://boringtechnology.club/

> 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.

> 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. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble.

> Any of those choices might be sensible if you're a javascript consultancy, or a database company. But you're probably not. You're probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail.

> 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.

The essay Choose Boring Technology covers some of this ground. From that essay:

"One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort."

https://mcfunley.com/choose-boring-technology

Another nice thing about the above essay is that it uses dark text on light background (as opposed to this blog post, which I had to print to PDF in order to read).

I have to say, though, that I really miss the days when I was the excited young programmer dying to use the new language, the new framework, the new paradigm or even just some design pattern. Lots of fun! Luckily, during those years, I was always in a team with a more level-headed and experienced developer who would bring me (and the other team members like me) a little closer to earth. And the level-headed developer was learning from us while he/she was moderating our technical ambitions.

Per "Choose Boring Technology" [0]:

> 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... 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. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.

From my POV, the author spent their innovation tokens on a political commitment. I would not recommend this path to someone starting a company. It's hard enough already.

Also, many American companies that might have been useful to the author were founded by Europeans, e.g. GitLab. There's plenty of European talent for making widely adopted infrastructure. If those companies aren't in Europe, it's worth asking why [1].

[0] https://mcfunley.com/choose-boring-technology

[1] https://worksinprogress.co/issue/why-europe-doesnt-have-a-tesla/

It's partially covered in the first link on the page: https://mcfunley.com/choose-boring-technology.

A specific quality described there would be languages that have fewer unknown unknowns, a lack of surprises. C, C++, Java (the three he picks) have relatively few surprises. Either by virtue of design (here I'd say both C and Java) or total industry experience with the language (C++, C, Java). Ubiquity might be another consideration. A lot of other languages could probably be added to the list on that criteria.

Another would be how common it is, especially for a particular domain. In my field (embedded, safety critical, real-time) it would seem like Rust would be a great choice, but it's not common and there are both technical and logistical hurdles preventing its use (for fielding, at least, for proofs of concept it's viable and that could lead to its use in fielded systems later). I'm constrained to C, C++, and maybe Ada. Fortran has been phased out, but would've been one of the boring languages for this domain up to about 20 years ago (for a new project).

Even with a clean slate, there's immense value in choosing something that you already know to be a tried-and-true approach - i.e. in choosing "boring" technology¹ instead of trying to be at the cutting edge.

Now if exploring the cutting edge is a goal of yours in and of itself, then by all means blow some of those innovation tokens on the new Reactangular.ts hotness. For a lot of projects, though, the goal is to get something out the door as painlessly as possible; jQuery and plain JS have (for better or worse) been the tried-and-true "boring" approaches, and HTMX (from what I can tell) seeks to be the similarly "boring" choice.

Obviously right now HTMX ain't the boring choice (because it's still pretty new), but a decade from now it could be. Having used it in a couple pet projects recently, it already does feel pretty boring (especially since it goes hand-in-hand with other boring strategies like "just use SQL" and "just use CGI scripts" / "just use classic MVC frameworks").

----

¹ https://mcfunley.com/choose-boring-technology