Do Your Job, Use Boring Tech

Standard

*LOVED* this article by Dan McKinley (blog: http://mcfunley.com/, twitter @mcfunley).

Read it in it’s entirely, I only have excerpts here.  http://mcfunley.com/choose-boring-technology)

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.

Photo Credit: KL_Photography via Compfight cc

Photo Credit: KL_Photography via Compfight cc

Lyal and I have always shared a very pragmatic approach to technology stacks, and hated the use of new tech just for the sake of something shiny.  Improvements on proven things, sure!  Use Laravel or Yii instead of Symfony, IDGAF, but “I want to make something in Erlang” => Get the fuck out.

Dan finally lays out a clear framework for this.  Your job is not to build tech or push the state of tech forward.  Your job (and mine, and everyone’s) is to build and grow a business.  For every task there is a best tool, but defining that narrowly creates a structure that can’t be understood or maintained.

Tech stacks should be built with the hit-by-a-bus scenario in mind – if your lead dev gets hit by a bus, you should be able to either modify the code with existing people, or easily recruit a replacement.  If you need another expert in Hack, you’re dead.

The other important aspect is the unknown-unknowns, the actually broken and buggy bits that still exist in every open-source component.  When I was running large-scale replicated MySQL in 2005, we still had crashes and data inconsistency occasionally, and had to talk to Monty about specific issues and changes.  Two years ago at another company, the CTO had chosen lots of Mongo, and the same thing happened – people didn’t understand the low level issues and intricacies, and things went wrong that were unexpected and took a lot of time and effort to solve.

So choose known, proven, solid at scale tech that you and your team understand.

Save your innovation for where it truly makes a difference in your competitive environment.

 

 

 

 

One thought on “Do Your Job, Use Boring Tech

  1. This is a lame example, but I chose to use the world’s most basic, cheapest, ugliest, DOS-looking veterinary practice software to run my hospital. The sole reason is that 10,000+ other clinics use it, making it by far the most common software on the market. Which means, when I hire new people. There’s a better than 50% chance they’ve used this program in the past, and I don’t have to teach them new ways to accomplish the same tasks. Had no idea you blogged, cousin! Nice!

Leave a Reply

Your email address will not be published. Required fields are marked *