alt Hacker NewsI'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.
Replies
> I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens"
It’s a cute way of saying that you can only do 2-3 new things.
The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool.
If you’ve ever had to estimate your stories/tickets/etc in “story points” or “T-shirt sizes” then “innovation tokens” is roughly the same.
If you haven’t had to do that, you’ve lived a charmed life.
> Engineers should understand requirements, risks, tradeoffs, and potential gains.
Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk.
Hell, I’ve been that engineer in my misspent youth. The post resonates with many of us because it describes hard-won wisdom of our mistakes.
> New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak.
Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.
> What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better?
In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework.
> 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.
“Boring” and “simple” are ways to convey that it’s good to be risk averse. It’s a bit of rhetorical flourish that helps drive the point home: choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it.
I see innovation as a guardrail against CV driven development. More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution - I remember more than a handful of projects failing (either undelivered or rewritten well under their expected lifecycle) around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end.
> What if you know NodeJS really well?
Then you consider it boring. I'm sure Node and MongoDB were singled out by the author because at the time of writing they were still relatively new and undergoing periods of rapid development and change.
> For example, I may think "New" means untested, but is that true?
The article answers this, and the answer is "no". New technology is one you don't know the details of.
> determine candidate solutions, and choose them based on their fit
That's quite hard to do for solutions that you don't know the details.
You have an objection to something. It's clearly not to the article's point, though.
Well your points are making sense in isolation whereas this article is making more sense in general.
> I'm a bit tired of "simple" and "boring" and other nonsense words in this field...
This is hilarious in sense millions more will be tired and exhausted by evaluating new and exciting technology endlessly appearing all the time.
People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"
"boring" means familiar. It should have more known unknowns than unknown unknowns.
> What if you know NodeJS really well? Or MongoDb?
Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.
This was written over a decade ago. I'd take it in that context. Lots of the tech they're talking about was being cargo culted en-masse.
So yes, pick boring tech, defined as the tech you know the sharp edges of.