Choose Boring Technology (2015)
This again...<p>The problems with boring technology are twofold. One, it&#x27;s about rejecting newer tech on a bet you don&#x27;t need their features. And two, it&#x27;s about choosing older tech because you assume it&#x27;s good enough for the one year, two year, five year plan. And there are a few places that falls down.<p>The first is when the new tech features are really strategically relevant to where your company is right now. If you need rapid deployment of new infra as you roll out installations for new customers, choosing manual CloudFormation config over Terraform could be a bad call. If you don&#x27;t know your target platform at this point, writing native code over something cross-platform like React Native or Electron could be an expensive mistake.<p>On the second, every time I&#x27;ve seen someone quote this essay at work, it has always been for a bet that has ended up problematic or at least mixed result. The first time I saw it was in a mildly heated debate about whether we should use React. I lost the argument and that org chose Knockout.js with JSPs instead. You can guess how expensive that &quot;pragmatic&quot; decision turned out.<p>The second time was at a startup where the &quot;boring technology&quot; was - ironically - MongoDB. Everyone there had worked with Mongo and our only prior RDBMS experience had been with Oracle and PL&#x2F;SQL. The result was a mess because noSQL stores only work when you have inflexible query patterns, which is the opposite of product iteration at a startup.<p>So I am sceptical. If you know where your business should differentiate itself, and what pressures it will be under, choosing a technology should be - if not obvious, at least a process you can follow. Relying on proxies like &quot;innovation tokens&quot; feels to me like a mistake because it is, fundamentally, trying to replace strategic thinking with a points system.