Spotting the Hype

29 November

Every tool, framework, language, technology, product, … can be evaluated with a metric which not many people know to use let alone practice. It can take a little bit to get used to, but it pays dividends quickly. 

It all started with a pet peeve. Have you seen any of this ridiculousness? 

“Build an X in 5 minutes!” 
(but we won’t tell you about the performance problems with this simplified approach or the bad habits you’re now starting with.) 

“Fork and deploy your own Y in under a minute”
(with undisclosed yet massive security vulnerabilities.) 

“Look how clean/fast this code is”
(as long as there’s no error handling.) 

“It automatically infers the schema”
(but only gets it right with contrived examples.) 

“If you think about it, it’s more correct this way.  Like a mathematic proof”
(and shockingly more complex with high churn.) 

If they cut corners to hype it then it sucks. 

Full stop. It’s marketing BS. 

It can be hard to see beyond the hype, so the secret is this: Implement something their way but evaluate it pragmatically, your way. 

New HVAC system claims to be the quietest but won’t publish half the usual specs?  Install one, publish your measured data.  It probably sucks. 

New web tech claims to have the best developer experience?  Make a non-trivial app following their guides.  Did the docs leave you with a database open to the world? It sucks. (Looking at you, Firebase, with your repeat failures on this audit.) 

On the bright side

Did the 5-minute tutorial start you on the best practices immediately (e.g. Rails’ database migrations)? It probably doesn’t suck. 

Did they disclose the problems you’ll have to address up front so you don’t have to discover them at the worst time? It probably doesn’t suck. 

And, to be fair, good tech might have crappy guides. As a result, though, it’s leaving you with unknown security risk, unknown timeline risk, unanticipated vendor-lock-in risk, among others.  So it still sucks. 

So you probably have a feel for the metric at this point: how direct and up-front are the pragmatic considerations in the guides?  Does it start with what you need to know or are the important things somewhere deep in reference the docs (or altogether absent)?