alt Hacker News> 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.
> It’s a cute way of saying that you can only do 2-3 new things.
Why? What if doing 1 new thing saves you from having to do 3 old things? Why 2? Why 3?
> 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.
I am not suggesting that you do something "because it seems cool". I'm suggesting that you evaluate the costs and benefits of technology, and that "boring" is not sufficient nor helpful in that evaluation.
> 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.
I've worked with plenty of engineers who dismiss technology because it is "hyped" etc and then try to build systems on top of databases or other tools that were never designe for the use case and fail miserably.
The issue in both cases is engineers not evaluating solutions correctly. "Boring" will not help. I have literally been in a meeting where "boring" and "innovation" tokens were the justification for a technology choice that failed miserably. More than one!
> Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.
I'm not sure what you mean. There's is presumably some technical solution to the problem you want to solve.
> 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 don't see why you couldn't justify not using Mongo or Node and then determine they aren't fits without saying "they aren't boring enough". In fact, I don't think either of those aren't boring in the sense that document databases/ nosql aren't particularly shocking concepts - the issue was, by far, the implementation.
> “Boring” and “simple” are ways to convey that it’s good to be risk averse.
They are very bad at this.
> It’s a bit of rhetorical flourish
I don't think rhetorical flourish should have much of a place in technical discussions. If you find yourself reaching for rhetorical flourish, you should ask yourself why you can't justify your position on its merits.
> 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.
New technology may not be orthogonal to it, it may be critical.