It's less of a message broker and more of a scheduler, although considering that both of them have some kind of queue at its core, the distinction is probably more superficial than it seems (a FIFO job queue is basically a kind of scheduler).

Spark has a scheduler that takes data locality into account (although I don't have a ton of experience with it and have no idea how well it works on a fine-grain scale). That itself is probably inspired from Borg and MapReduce, both of which have some kind of data locality-based job scheduling logic.

All hail YAGNI, the god of code.

Gotta give him credit for owning up.

Twice is extremely optimistic though... Especially if you give it a couple of years to forget your original thinking.

This is why people write tests.

It is brilliant... but I think it's a false dichotomy. I'm sure code can be clever and easy to debug. If it's designed in a way that is impossible to debug is it really that clever? I've been using react and redux a lot lately, and the design patterns make the code much easier to debug, and I'm not experienced enough (and probably not even clever enough) to have written them myself. It's like saying that smart people always use big words and hard to parse sentences - it's more of a display of cleverness than actual cleverness.

YAGNI.

By the time most people realize the site is not responsive or nice looking, they have will consumed about 80% of the content they will ever consume on it. No point in making it more responsive. It’s a diminished return.