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