I am reminded of Fire and Motion. Microsoft may be infamous for introducing new frameworks with alarming frequency (purportedly to keep competitors off balance), but the same could probably be said for a series of blog posts about switching to mongonodelastiscala.
Please tell me more about ElasticScalaDis!
I like this talk. I like the perspective on switching costs: it might not be that hard to swap out Redis for Memcached one week into scaling problems (that upfront legwork), but doing it a year or two later is much different. The original devs might not be around, they might be busy, et cetera. Uncertainty in when the rewrite might need to happen leads to uncertainty in the switching cost.
Communicating these decisions over time is hard; an email/slack thread might not be available to future devs.
That’s a good reason to write design docs when making thee changes.
I’ll respond the same way I did when this was just a blog post: without a definition of boring, this is useless. I find Redis indispensable. I understand it, I like it, and its advantages over the unstructured pile of data that is memcached mean that I will choose it for any project I work on in the future. I despise MySQL and have worked for weeks trying to fix performance issues and plain old badness (and trying to sell those fixes to people who didn’t understand what was happening…) that would not have been issues in a capable database (PostgreSQL).
When does a technology become “not boring?” I mean, Scala is in use at many large companies. It runs on the JVM, which is the definition of boring, right? Why is it not boring? Haskell has been around longer than Python, Ruby, or PHP. Common Lisp has been around even longer (almost as long as C++)! Speaking of which, why aren’t we just using C++? Java wasn’t boring in 1998, but people certainly started using it instead. Or, you know… COBOL! Good, boring history there. If we didn’t spend our innovation tokens on writing Ruby instead of COBOL, maybe we could make better software.
I think boring is relative to the team using it. I wanted to use a KV store on a project, and it would have worked wonders, but it would have been too much for the dev and ops teams. It was not the appropriate technology for that group. In this case technology can be very generic, if you are on a team where everyone is versed in compiling and parsing, it might make sense to make a small high performance DSL to solve a particular problem. Others might just use PCRE+JIT and others might just generate some PHP with Python and send it into HHVM. It all depends on how the group can adapt to using a new technology.
That’s fair, but the post mentions the burden of maintenance when the people from the current team have “moved on;” that implies a certain level of lowest common denominator programming, which I think has generally had a bad effect on our industry.
I’m not sure if the corresponding article has been posted here, but it contains the same basic content in a much more usable form.
It has: Choose Boring Technology.