Choose Boring Technology (2015)

I’ve found boring in this context to be a function of 3 things (in no particular order): - Your experience using the tool in question to solve this problem or very similar ones - Your teammates’ experience using the tool in question to solve this problem or very similar ones - The world’s experience using the tool in question to solve this problem or very similar ones

The specific drivers of this tend to be a mix of problem-solving pattern matching ie “Hey, we know what the usual suspects are know when things are slow/crash”, and ecosystem robustness — what is the probability of you being the first to trip a bug in a dependency / has a library been used to solve 10000 problems or just 3 — It’s more likely that APIs have been sorted out, bugs have been closed, etc. or that your team knows the quirks.

As an example, OCaml might be a relatively boring choice for writing a theorem prover, but for something like a RDBMS-backed web application, things are a lot more “interesting” as you go off the map much sooner.

As relevant as ever. It's fascinating how big web stacks are these days, even for small-to-medium sites: various combinations of at least one styling language (SASS/LESS/CSS), frontend framework (Angular/React), frontend language (JavaScript/TypeScript/Node.js), backend framework (Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java), and message bus (ZeroMQ/Redis/RabbitMQ). That's just the frontend and backend. Then there's infrastructure: pick at least three infrastructure as code components (Puppet/Chef/Ansible/k8s/Docker/Docker Compose/VirtualBox/WMWare/heaps of shell scripts), at least two web servers (Apache/nginx/traefik/your language's built-in server), and at least two TLS certificate providers because someone's nervous about moving everything to Let's Encrypt. I'm well aware that these don't have identical feature sets, but that's the point of the article: choosing a small and boring set of technologies is an advantage, not something to be ashamed of.

I guess that depends on your specialization. If you build backend services with Java or C++ the job market is pretty big. Probably bigger than if you're a Go expert but don't know Java or C++.

SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is almost all around trying to make this extremely un-boring application style more boring.

The SPA is a gateway drug to spending lots and lots of innovation tokens, more, really, than almost any dev team can afford. For example, I would consider each of Webpack, PostCSS, TypeScript, React, Redux, RxJS, to be rather exciting, and that's only a few of the exciting parts of a mature SPA project. And of course this doesn't touch REST, GraphQL, CI/CD, testing, metrics, telemetry and all the other excitement.

So, yeah, I would say that if you take the article seriously for a webapp, you'd limit yourself to a really boring Java (8) server-side architecture using Jetty, JSP, Spring, a service layer, over Postgres. Maybe an nginx proxy if you want to get a little spicy and have good SSL and static serving performance, and an option for simple load balancing later. Oh and the only provisioning you get to do is individual VPSs or even better, bare metal on prem servers! Git and Jenkins is probably boring enough to use, though.

But yeah, no Docker, K8s, OpenShift, no AWS other than EC2 and maybe S3. Probably no CloudFlare. Google Analytics, sure, but only if you don't care about your users privacy. Sentry is too exciting.

And then on the HTML side I'd argue that your templates should produce plain old HTML5, CSS3 and ES6. No transpilation, no source maps. No official support for IE 11. And even for those languages you can cut out the most exciting features. Do you really need the "class" or "new" keywords in ES6? For JS modules, use the boring, built in browser module system (you knew it had one, right?![1])

1 - https://caniuse.com/#feat=es6-module-dynamic-import

The risk of this attitude is that you may never get enough experience in a technology to approach expert level. If we're constantly reinventing the wheel, it means we never really have a chance to use that wheel to go anywhere.