Slashdot Mirror
Why You Should Choose Boring Technology
An anonymous reader writes Dan McKinley, a long-time Etsy engineer who now works at online payment processor Stripe, argues that the boring technology option is usually your best choice for a new project. He says, "Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. 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. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble. ... The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood."
A personal corollary for code related to this theme is to always try to make the code I write as "boring" as possible. I've found that programmers often get themselves in trouble by trying to be "clever", which often makes for horribly unintuitive or unnecessarily complex systems. I've heard people asking about how to perform crazy language tricks and I nearly always think to myself "My God, why in the hell would you even *think* about doing something like that?" Such things nearly always point to very fundamental flaws elsewhere.
Irony: Agile development has too much intertia to be abandoned now.
Mature technologies are proven. They've gone through their growing-pains. They may have limitations, but those limitations and workarounds are usually well known by seasoned professionals. There's a reason why COBOL, Fortran, and RPG are still in use in business applications almost sixty years after their initial development, because they reliably work.
I've tried to work with NodeJS projects for production. It's a nightmare. NodeJS itself is revised too often, the actual project is revised too often, and the dependencies became a nightmare. It's not mature enough and not worth it.
Do not look into laser with remaining eye.
I've recently been getting more heavily into javascript (proper apps, not just UI animation snippets). The whole scene is a mess. You try to learn about good code structure and you've got crockford saying use constructs to simulate classical OO and then a whole lot of other coders giving you really good reasons to use prototypical inheritance and stop trying to simulate a classical language. Then a whole other bunch are telling you to use coffee script but others point out the difficulties debugging it so then you should use typescript because it will eventually be ecmascript6. Once you get your head around the code structuring options, you then have to decide whether to just use jquery or an mvc like ember or angular. And when you choose a shiny new bbc because it is easy you realise that two way data binding makes your code super slow and start having to hack away at it to get it working on a mobile targets. Oh and don't forget the TDD framework unless you go for BDD because that is the new thing. And then do you use the closure compiler, requirejs for amd or should you even use amd at all.
I will happily go with tried and tested, if only web developers would stop reinventing things every six months.
I would never describe Perl as boring. Annoyingly random, and obtuse, but never boring.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Oddly enough, I've seen that cause more problems than it's solved.
It's often misinterpreted, in the same way you so conveniently put it, which is then used to justify some pretty awful decisions regarding third-party libraries. I'm convinced that this is the leading cause of bloated software.
Even when used correctly, I've seen some pretty impressive code-contortions to avoid even a very small amount of duplicate code. Sometimes, it's okay to just do a check twice. As long as the code is easy to read and modify, you're fine. Really.
But that's the problem with programming, isn't it? It's little more than wishful thinking and folk-wisdom. That would be okay (it's an art, after all) but too many developers have deluded themselves in to thinking it's more in-line with mathematics or engineering. They've convinced themselves the cute little acronyms they repeat to one another have some objective, rational, basis and must be obeyed at all cost.
It's silly, really.
Required reading for internet skeptics
Yes, but his brilliance was in minimising the number of components required to perform a certain function. His "art" was in solving two pragmatic problems. a) Correct function of device and b) minimising the costs (components). The constraints (physical and budgetary) are what channeled his creativity.
You have a good point, but only most of the time.
Thomas Kuhn, in the context of science, spoke of 'normal' and 'extraordinary' science. Normal science was as you described; you stay in the paradigm and follow the conventional methods for resolving issues. However, these methods did not appear out of nowwhere; somebody was being a clever cowboy and decided its time to do things different. This is where revolutionary science came in. Of course most of these innovations - like any innovation - fails miserably. But if it wasn't for all the failures we would never have the successes that change paradigms and got us to the methods we use today.
And I think this dichotomy does apply to almost every human endeavor.
That said, for normal day to day operations, being a cowboy ALL the time is foolhardy and dangerous. But for people to NEVER have a little bit of an experimental and innovative mindset is also risky in its own way. Sometimes this is balance (known as a bimodal or barbell strategy) is maintained within a single individual by balance of exploiting the traditional and exploring the novel; sometimes its divided between individuals, with a good balance keeping more people stable than unstable.