![](\"https:\/\/lh6.googleusercontent.com\/c90Ek5pZ-SqFMROvCL-iKL_-FXp7A2jfLCIIvO6yHIIpKeQcZQ7d3S34-JOY_RpAQy_ZFoFf17syCoPO18r0ZdSpusISdI4LWlw3PDr-LJkO_2aP60_NGZlrOnSeGLw3gagaLyXM\")
<\/p>\n
\u201cAll this fuss over nothing. All this searching for something, all this reinventing the wheel, all this searching for something, that\u2019s not real\u201d<\/p>\n
The Wheel, SOHN 2017<\/p>\n
I\u2019ve had a riff for a while about Developer Time To Suck, the half life of a product or project before developers decide it is time to find something else bright and shiny to play with. It used to be that a new technology had a few years before it was seen as boring. In tech, like in politics, you were the future once. But the window is shrinking all the time.<\/p>\n
It used to be that a developer choice was cool for about five to seven years. Today not so much.<\/p>\n
MongoDB is a case in point. It went from the new hotness, adopted by a bunch of 23 year old \u201carchitects\u201d surfing the Node.js is Bad Ass Rock Star Tech wave, to the same people saying it totally sucked two years later. For mongoDB that was OK, because it\u2019s convenience meant that enterprises had also adopted it in significant numbers – so it has a market to sell into.<\/p>\n
Web companies are doing much of the development of core infrastructure today, and they have a far higher tolerance for disposability than vendors or enterprise customers. The combination of open source, cloud deployment, and social coding means that developers are building, and exposed to, more cool new technology than ever before.<\/p>\n
Hadoop was the bee\u2019s knees for about 5 years. Then, just like that, streaming was the\u00a0 new thing, and everyone pivoted to Spark and Kafka stacks.<\/p>\n
All this newness has a cost though – in terms of production deployment, but also sheer cognitive overhead. In 2014 my colleague asked: A Swing of the Pendulum: Are Fragmentation\u2019s Days Numbered?<\/a>\u00a0In 2017 we can fairly safely answer – no. In every category we track we\u2019re seeing cool new things emerge that developer want to use in production.\u00a0 Pony and Rust are going to break out any time soon.<\/p>\n But Ops of course has always had to take up the slack, or should be take up the stack<\/em>. Running the thing in production is not the same as running things on your laptop. Except of course, when it is. Clearly the direction of travel with container technology is to collapse distinctions between development and production environments. From a testing perspective we want local and deployment to be as far as possible the same.<\/p>\n As Ben Fletcher, Principal Engineer said in his excellent talk at Jeffconf<\/a> recently:<\/p>\n \u2018We don\u2019t like pre-production. We like localhost\u201d<\/p>\n The organisation the FT runs is very much a web first operation, rather than a more traditional transactional enterprise shop. Not everyone is going to do multiple production deploys per day but that is direction of travel. It\u2019s not just enterprises that sustain technical debt of course. We\u2019ve had some fascinating conversations recently with startups that are unable to keep up with Amazon Web Services (AWS) pace of innovation. While they\u2019d like to adopt AWS Lambda for example for some functions, they\u2019re already bedded in a stack built on earlier AWS stacks.<\/p>\n This tweet got me thinking<\/p>\n Wondering what it must be like working on the edge, in an industry that does not half life its execution stack every 6 months.<\/p>\n — Karanbir Singh (@kbsingh) July 17, 2017<\/a><\/p><\/blockquote>\n\n