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."

5 of 232 comments (clear)

  1. Re:I agree .. BUT .... by Lodragandraoidh · · Score: 3, Informative

    Every organisation needs a "not boring" slot of time for their developers. Not for product that needs to ship NOW.. but for stuff that may need to ship next year.

    /agree/

    Except I would add: "may never ship at all."

    The key point here is you aren't betting the company on it, but you still should be doing it. Every company should encourage innovation - and even if the company isn't willing to bet any cash on it. Another way is to encourage your developers to spend some time on their own personal FOSS projects. What this gives you is experience - and from a risk vs. reward perspective, success is attained not by how much working (boring) code you produce, but really how many times you try something that fails, and get up again and keep pushing on with new/modified ideas based upon this experience giving your customers real value. Companies without this perseverance will fail, or at best will be mediocre.

    On the flip side - if your core business (the part that you are trying to show your customers you are innovative and a leader in) becomes too boring - and by too boring I mean while it may 'work', it may not do what a customer really wants/needs - then you run the risk of losing those customers to someone who will try and be willing to fail.

    Just like all oversimplified prescriptions, the article's concept does not take into account the nuances of business goals, risk aversion level, available human factors and skills, and so on.

    --

    Lodragan Draoidh
    The more you explain it, the more I don't understand it. - Mark Twain
  2. Re:A Corollary for Code by readin · · Score: 4, Informative

    I was recently explaining to some students why I don't know about the trickier parts of the language I use everyday. I don't use those tricky parts and I would chew out anyone on my team who did, so the precise details of how those parts work never come up..

    --
    I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
  3. Re: A Corollary for Code by Anonymous Coward · · Score: 2, Informative

    Also, like being sexy, be sensitive of how you age... some can do it, some cannot. I was clearly in your second group a few years back... now that I'm getting older, value sleep, try to avoid the hypertension that was destroying my heart, have to manage other people that also code... being in the first group is fine.

  4. Re:A Corollary for Code by Anonymous Coward · · Score: 2, Informative

    For pretty much every tricky language feature, design pattern, complex algorithm etc you'll run into, there exists a project that uses it correctly and gains significantly from that. The problem is that there are so many of them that you cannot expect to be able to master them all no matter how good you think you are. A good developer understands this balance while bad developers go to either extreme.

  5. Re:More... by TheRaven64 · · Score: 3, Informative

    The original justifications for hating goto referred to a non-local goto (or, exceptions, as the kids call them these days) which made it very difficult to reason about control flow in a program. The new reasons for hating goto in language like C/C++ relate to variable lifetimes and making it difficult to reason about when variables go out of scope.

    --
    I am TheRaven on Soylent News