I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themselves because the software world had moved on and left them behind.
Later, I worked at a smaller company that let a young talent bring in a newer, more complex technology stack, made for solving problems at a scale they not only didn't have, but would never even aspire to reach. His reason was clearly that he wanted it on his resume; it took me a while to figure out that was his supervisor's reason for letting him do it. Both probably left soon after, leaving behind a higher maintenance load that would have helped them only if they reached a scale 1,000x bigger than there was any prospect of.
These two cases (and several others like them) have convinced me that it is possible to screw this up in either of two directions. No doubt there is a good rule of thumb to determine how to get it right, but I haven't found it yet. The best I know of is, to be aware that it is very possible to get this wrong in either direction.
"Choose boring technologies" doesn't imply "... and then never change ever again even when it becomes obsolete and unsupported". That's where the first company went wrong.
It means to choose technology components that are stable and boring (but still actively developed with a healthy community around them!).
It also means to break this rule if and when that thing is important enough to your success that it makes sense to spend innovation points on it because it'll set you apart. But also recognizing that those instances are rare, and that's where good engineering judgment and leadership comes in.
"Choose boring technologies" is one of those phrases that makes sense when it makes sense, unless it doesn't. I find the negative expression of the same idea much more fitting: "Don't choose technology purely out of exitement".
In that negative version the word purely does the heavy lifting: If all you have as a reason to choose a thing is excitement it might be a bad choice unless you can afford a failed attempt.
In reality very often the "more exciting" choice will also come with their own additional pros/cons. It might be that your exciting Rust-Webservice has a smaller community backing its components, but maybe the APIs of the few components you really interact with is such a joy to use that it will save you weeks over the Java equivalent, while giving you magnitudes faster startup times and decent testability.
In programming there are so many angles to consider, that simplistic answers are rarely do reality justice. There is however the danger of wearing rose tinted glasses when weighing the cons of the more exciting solution.
Agreed. The first scenario really suffers from conflating "boring" with "obsolete". If anything, most exciting technology has a much higher propensity to becoming obsolete than, and also long before, most boring technology does.
Yes I think this is the key insight: if you have two technologies that will solve your problem, both reasonably popular and actively developed, the one that is ten years old is far more likely to still be actively developed in another ten years than one that is one year old.
Well, only if both work about as well as each other. Good technologies are likely to outsurvive bad ones once the good ones get a minimum of popularity.
I would say that technology that requires constant (re)writing of everything cannot be called boring. I could writing a project in COBOL, which is an old technology, but certainly isn't boring. Its age has actually made it “exciting” (that is, the opposite of “boring”, regardless of the actual feelings working with it would result in).
>I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themselves because the software world had moved on and left them behind.
Can you expand on this? What was the boring technology?
A proprietary programming language called "Natural", and an associated database called "Adabas". Both actually had some advantages, and the internal culture had developed effective ways of working around their limitations, but being proprietary, and that old, had definite downsides.
The problems with boring technology are twofold. One, it's about rejecting newer tech on a bet you don't need their features. And two, it's about choosing older tech because you assume it's good enough for the one year, two year, five year plan. And there are a few places that falls down.
The first is when the new tech features are really strategically relevant to where your company is right now. If you need rapid deployment of new infra as you roll out installations for new customers, choosing manual CloudFormation config over Terraform could be a bad call. If you don't know your target platform at this point, writing native code over something cross-platform like React Native or Electron could be an expensive mistake.
On the second, every time I've seen someone quote this essay at work, it has always been for a bet that has ended up problematic or at least mixed result. The first time I saw it was in a mildly heated debate about whether we should use React. I lost the argument and that org chose Knockout.js with JSPs instead. You can guess how expensive that "pragmatic" decision turned out.
The second time was at a startup where the "boring technology" was - ironically - MongoDB. Everyone there had worked with Mongo and our only prior RDBMS experience had been with Oracle and PL/SQL. The result was a mess because noSQL stores only work when you have inflexible query patterns, which is the opposite of product iteration at a startup.
So I am sceptical. If you know where your business should differentiate itself, and what pressures it will be under, choosing a technology should be - if not obvious, at least a process you can follow. Relying on proxies like "innovation tokens" feels to me like a mistake because it is, fundamentally, trying to replace strategic thinking with a points system.
"Choose boring technology" is important not because it's universally right. It's important because it combats a problematic bias in the tech industry.
Individuals within an organization are strongly incentivized to choose exciting technology. Not only is exciting technology more fun, it's also a new thing you can put on your resume, and the implementation of it is often an opportunity to demonstrate the architecture and design skills that are necessary to get promoted at many places.
As you've pointed out, "choose boring technology" is wrong in many cases. However, it gets trotted out so often because, before this essay, it was very hard to combat the "choose exciting technology" bias that permeated many engineering orgs (and still does to this day).
Exactly. Where I work, we've explicitly chosen to "choose boring technology" in the parts of our stack that aren't key differentiators in our product. The idea goes back to the concept of "best practices" being essentially "what everybody else does," which essentially means "good enough, unless it's something that needs to be better than good enough." In essence, this has lead us to a philosophy that's very close to (but not quite) "AWS is our architecture 'standard library.'"
We also define "boring technology" a little differently than the post does, I think. Basically, we think of it as "stuff that isn't going to page me in the middle of the night and wake me up." For us, because we're already on AWS, that tends to be AWS managed services, except for the services that directly provide functionality to our product, which we run containerized on EC2.
Essentially, our comparison between AWS managed services and running some other service ourselves to meet the same need comes down to cost. If it costs less than about 3 engineers' salaries to run the AWS service, we're happy to hand off the pagers to them rather than wake up our engineers when those services get unhappy.
We also apply this philosophy to our custom services. Right now, we have a monolithic web app that runs on Python + Flask + SQLAlchemy. So, by default, any new services run on Python + Flask + SQLAlchemy. Not FastAPI, not Django, not Rails and definitely not node.js. Python + Flask + PostgreSQL + SQLAlchemy, unless you have a convincing case for running something else. Not only is this extremely boring technology (Python has been around for ~30 years; Flask 12 years; SQLAlchemy 16 years; and Postgres -- who cares, we use it via RDS and let Amazon manage it), but we won't have to try and hire people who know Scala, for instance.
We're also not above stealing large portions of our architecture, when appropriate. One good example is that we've essentially lifted the auth system for our new API from an example in one of the AWS blog posts. It works. We know we won't have to worry about it in the future. It's boring, and not a core feature of our product, so we don't want to have to care much about it.
None of this isn't to say we don't have a lot of exciting stuff going on inside our product. We do. It's just that we have deliberately chosen for our non-core functionality to be boring and run on boring technology that's mostly managed by other people. I guess that's a little like us choosing to spend our "innovation tokens" wisely.
> "Choose boring technology" is important not because it's universally right. It's important because it combats a problematic bias in the tech industry.
Instead of combating a dumb bias with a dumb catch phrase, why don't we say the right thing?
Choose the technology that fits your requirements. If you don't know your requirements, learn them, or remain flexible.
Sure but "choose boring technology" is the right default for an organization. I think any new technology brought into an organization comes with a cost and that cost needs to be justified.
But “requirements” are hard. In a given organization everyone will have different opinions. Even more importantly, the same individual will have varying opinions based on their current context.
What if one of your requirements is “retain talent because the longer they stay and know the business, the more valuable they are.” But boring those employees with the same old never change anything approach will drive them away.
My biggest gripe with the choose boring technology mantra is that it often conflates with a sort of tech populism. Populism often creates short time wins for long term losses.
I actually think the bias can go either way. Sometimes, technologists are suspicious of new practices and assume the motive is neophilia
You can see this in McKindley's talk. Developers who want productivity improvements are just after "shiny things". Because they're stupid, like kids or animals, get it?
It's possible that you and I have different experiences. But many times I've seen people at FAANG gunning for that coveted E6/Staff promo choose new technology even when unnecessary, because it's hard to find projects that demonstrate the skills needed for that promo.
The context also matters. If you're working on a small team with low attrition, the cost of choosing new technology is low. If you're on a large team or in a high attrition environment, the costs for choosing a new, unfamiliar technology are astronomical.
I personally find that most developers (especially those in a web related field) tend to shift to newer technologies when there is very little reason to do so, and perhaps more importantly, be an evangelical today. Ask yourself this: do you seriously think that a company would benefit from switching stacks every few years, or sticking with a mature and battletested technology?
I find that this happens mostly due to career expectations.
Gotta stay up to date to get the recruiters chasing you.
But when everyone else is also up to date, gotta stay ahead and be an influencer/evangelist.
> Ask yourself this: do you seriously think that a company would benefit from switching stacks every few years, or sticking with a mature and battletested technology?
In my experience this is unfortunately situational, and depends heavily on who's answering. Someone who loves the current stack will say "don't change it". Someone who loves the next stack will say "yes burn it to the ground". Both of them, after doing a bit more self-reflection, will probably say "well, it depends, but probably not".
I personally find that folk online who accuse "web developers" of neophilia over-estimate the amount of change in webdev and show little interest in the motives behind new practices.
For instance, calling React "yet another new framework" when it's eight years old. Or loudly opining "why does everyone want to stop writing traditional CSS? These JS programmers are idiots" rather than pausing to reflect that, actually, CSS might actually have a bad reputation for a reason.
Nah, the phrase is "choose boring tech", not "choose convenient tech".
The problem is that calling out "resume-driven development" triggers the resume-driven developer. They're enraged but they don't know why they're enraged. They feel condescended, like they're being treated beneath their station. Instead of digging into this feeling, the resume-driven developer just blames other people. The possibility that maybe the resume-driven developer is overestimating themselves & confusing the word “fun” with “productive” never crosses their mind.
Yes, this again, because it is the single most important and common error developers make today.
> The problems with boring technology are twofold. One, it's about rejecting newer tech on a bet you don't need their features.
No, it's about rejecting newer, complex tech when you demonstrably don't need it, and the real reason it was chosen is that developers like shiny new toys that are cool because other developers are all talking about them.
> developers like shiny new toys that are cool because other developers are all talking about them.
I refer you to my other comment about the profound misanthropy behind "I don't understand why people want more productivity so I will compare them to children / animals"
> I don't understand why people want more productivity
My assessment is that "want more productivity" is, 90% of the time, a nice-sounding smokescreen for what is in fact neophilia.
I'm making an empirical argument, not a philosophical one. It's based on personal experience with many devs. There is a massive bias toward trendy technologies, and they are rarely chosen for objective, research-based reasons.
What you are reading as "profound misanthropy" is coming from hard-won experience: I have seen the disastrous consequences of these decisions, the developer-years of wasted time, and in some cases had to clean up the mess myself.
> Relying on proxies like "innovation tokens" feels to me like a mistake because it is, fundamentally, trying to replace strategic thinking with a points system.
No, it’s making it clear that there’s a scarcity you have to manage that is non-obvious: too many novel tech choices and you end up getting burned by the sum of all their risks leading to perpetual problems. If you have engineers literally allocating themselves a fixed number of tokens they don’t understand the talk.
So why use any novel technologies, then? Why don't we use tech from the 1990s? Is it just neophilia?
Or is it that tech companies, by their nature, are about automating new things by applying, building, leveraging new technology? And that they are invested in because people want to make a bet on those productivity multipliers?
I get some of what you're saying, but a lot of your posts caricature OP's position. They're not saying "don't ever choose new technology" or "never upgrade your programming language" (e.g. staying on Java 6). They're arguing that there's a human dynamic that tends to focus on the benefits of new tech without acknowledging the costs and risks, and not accounting for that dynamic can be ruinous.
Evaluating technology choices is hard. There are a lot of moving pieces. Sometimes it's 100% the right choice to use Django or Hugo; others it's 100% the right choice to use Nuxt.js. This presentation gives engineers tools to better evaluate the tradeoffs involved. It is in some ways a polemic, but to me that's just to make it an interesting presentation.
Boring technology is not necessarily the same thing as older tech. Lisp, for instance, is much older than Java, yet Java is clearly in the category of "boring" technology, whereas Lisp is quite the opposite despite its age. It seems that for tech to be "boring" means merely that it is a safe choice for the task at hand, a tool that will certainly do what needs to be done, with the kind of ecosystem and stability that leaves little room for the unexpected, for exploration. There is no significant uncertainty involved in the use of such technologies, which makes them "boring".
> One, it's about rejecting newer tech on a bet you don't need their features.
Not really. It's more a bet that the limitations of the new tech - bugs, missing or incorrect features, lack of support, etc - will outweigh the benefits of the new tech's features.
> And two, it's about choosing older tech because you assume it's good enough for the one year, two year, five year plan.
This is often provably true, because you can point to personal experience where an older tech has been good enough for a five year plan.
I think PostgreSQL is the ur example of this. Every once in a while, a new hotness comes along, ready to dethrone Postgres. Monog was the one I got caught up in. Mongo was so much easier to use, from a developer's perspective. The install was easier, the API was easier, clearing out test data after each run was easier. I loved it.
But it also wasn't ACID compliant. Oops.
> If you need rapid deployment of new infra as you roll out installations for new customers, choosing manual CloudFormation config over Terraform could be a bad call.
Terraform is seven years old. It's not new tech, it's a proven, industry standard.
And that's kind of the unspoken assumption of this piece: if your focus is on production, let someone else play with new tech until it becomes old tech. Let them assume the risk.
> The first time I saw it was in a mildly heated debate about whether we should use React.
This essay isn't saying "don't use new tech," it's saying "use new tech responsibly," and "limit the number of unknowns in your production system." It's saying that "going fast" and "cool new features" needs to be balanced with "reliability" and "support."
And React is also eight years old, so it isn't a new tech, either. It's one of, if the not, de facto standards. I don't know when your team had that conversation, but React is a tech that fits very comfortably into the "we know what sucks about it" category, and has for a few years now.
So does NodeJS, which is on his slides as an example of spending an innovation token. Tech marches on. Our understanding of it advances. Stuff that was new becomes old, and stuff that's old becomes obsolete. This essay isn't saying "don't move forward," it's saying "don't pick something because it's new, pick something because you can prove that it will help you."
> The first time I saw it was in a mildly heated debate about whether we should use React. I lost the argument and that org chose Knockout.js with JSPs instead. You can guess how expensive that "pragmatic" decision turned out.
This is an interesting one to me from the opposite side of the decision: I was at a young startup that was a very early adopter of React, and I felt like it slowed the team down at that time.
Even though it eventually became dominant, the ecosystem had pretty limited tooling early on, and it seemed like our team spent a lot of time coming up with in-house solutions for things that were eventually solved by definitive libraries (e.g. Redux). From my point of view it had a pretty tangible impact on our time to market for some important features vs using something less shiny.
I’m not sure I’d have chosen Knockout and JSP instead (though I was a fan of Knockout at the time for small projects and feel like Vue is a great spiritual successor to it), but the experience certainly colored my decision making in the years since.
Knockout was an abject disaster. We almost immediately ran into performance problems. Coupled with its own limited ecosystem we had the same problems as you experienced with React, but ended up in a far worse place.
I have reflected on what happened quite a bit and I can't think of any redeeming aspect of that technology choice. It really was the worst possible move and it was entirely motivated by the "boring is better" argument.
Pretty sure this submission follows from this post https://news.ycombinator.com/item?id=31558748 (in comment to the 2nd top entry on the front-page at the moment). So maybe it should be read in that context. Eg: which dryer to buy as a consumer, not which API framework a startup should invest into (even though there are overlap, of course).
You also have so many hiring tokens. Not every company can have market beating comp, or high likelihood of super profitable stock, or world class super nice offices. Having exciting tech can be an actually cheap way to attract top talent.
Sure, but if that's the appeal, it tends to attract the kind of person who looks at an old Rails app, and decides rather than cleaning it up the thing to do is replace it with a sea of graphql-fronted microservices that's nearly impossible to work on.
There's other extremely cheap ways to compete: be family-friendly, open to remote, have sane processes, etc.
Codebases in old tech and new tech can both be bad. I don't think that's necessarily an argument against either. Part of getting good people is getting people who want to build maintainable and solid stuff.
> There's other extremely cheap ways to compete: be family-friendly, open to remote, have sane processes, etc.
Of course. Depending on how badly you're struggling to hire, you might need to do a bunch of these.
Only tangentially related to your comment, but I've seen a very clean pattern where "the tech I'm going to use on this project" maps very neatly to "the tech I want to have on my resume the next time I'm looking for a job." I think someone called it resume driven development.
Absolutely true that, but it can also be a way to make your maintenance needs require exotic skills you didn't need before, such that your already-scarce hiring tokens are stretched even thinner once that new person builds their thing and moves on.
Which doesn't mean your point isn't valid, just that there is a flip side to it that it should be balanced against, and it is possible to err in either direction.
I was just thinking that I could likely make a reasonably accurate guess to commenters age based on their reactions to this article.
But you trigger an interesting question. Frankly, part of my value to an organisation /is/ the accrued scar tissue from working with exciting technology; "choose boring technology" has us greybeards nodding along as at least half our job is about saying "no" to things - by being good at making the value judgements about when something shiny is worth it, and to be worried about those unknown-unknowns as you're gonna get the call when it breaks at 3AM on a weekend.
But: We're clearly not learning from this. Maybe if we don't let people burn themselves they won't discover the stove is hot? Is this just the way of things, or a function of the fact that older engineers are steadily driven out into 'management', and the industry keeps re-inventing the wheel every 5 years?
A lot of new tech is also spun out of large companies where the original ideas were piloted internally (see Kubernetes, Bazel, a number of distributed databases)
I'm generally a fan of this, but following this too closely will eventually kill your company. Every currently boring technology was once a new hotness and eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc.
Put another way, this is a very fragile strategy. It consistently protects you from small, limited downsides, while opening you up to the occasional collapse. An organization which is constantly experimenting with new things will pay a consistent cost for all the failed experiments, but they are opening up themselves to huge upsides if one of them works.
> ... eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc.
I am yet to see a company that is running their apps in Tomcat, Java and MySQL fail badly, even without containers and microservices or service meshes and serverless, since those generally tend to all be orthogonal to getting things done for most of the projects at the scales that my country (Latvia) needs.
I think your point could be applicable in two particular cases:
- where hype cycles affect the corporate policies and suddenly it's mandated that Kubernetes and microservices are used, because someone either likened their org to another that's 10x larger and has more resources, or just wanted to pad their CV/make their work sound more important; suddenly companies that don't use said tech cannot successfully work on any development contracts with said org
- alternatively, where the projects actually need certain new technologies or approaches (aforementioned architectures, tools, things like machine learning etc.) for either large or interesting systems
I don't believe that most boring enterprise systems out there will conform that much to either of these, unless you're working for a large org with huge projects. Definitely not for orgs that have technology not be a primary means of getting done (or at least isn't prioritized as such) and for whom a simple CRUD would suffice. Or, you know, governmental projects that are acquired through mountains of documentation and specs, most of which will change anyways.
Scale and the industry matter a lot here, there is no one universal truth - in highly competitive markets, you're probably right!
I have seen such companies fail as they struggle to hire and it becomes more difficult to adapt quickly to more spry competition. If they are in a market without spry competition then it works fine. For instance, for internal applications where there is a top-down forbiddance of experimentation with new things. But even for internal apps, if experimentation is not forbidden, a forward-looking team might start effectively using (and hiring for) newer technologies and eventually get all the budget.
The other part of the problem is that in a limited hiring pool your competition's labor pool overlaps quite directly with yours and now you need to have compensation packages similar to theirs potentially. I've seen companies have what amounts to the same stack as a large F500 enterprise (Java, Spring, AWS, etc.) and have massive hiring problems, turnover, and especially velocity of features to keep ahead of the big companies. Essentially, if you cannot iterate faster than your competitors sufficiently from the same customer market and hiring pool, you are designed to fail or in best case be acquired by your competition.
There is a balance to be achieved between boring technology, boring customer market, boring hiring pool, and so forth when it comes to any company. You need at least two such major advantages to even bother starting a company IMO.
Well, in non-competitive "markets" like government services, your failure will just manifest itself in different ways. You will still fall behind more agile organizations, but instead of your company going bankrupt, citizens will increasingly view the government as inept, loose trust, etc. A terrible enough digital infrastructure will eventually become a drag on your GDP and lower your standard of living relative to other places.
What's funny about your quotes is that Kubernetes is now 8 years old, very mature, very capable, widely-used, well-understood, with lots of tooling and wide-spread know-how. It is "boring".
(this got kind of long, might make it into a blog post later)
> Well, in non-competitive "markets" like government services, your failure will just manifest itself in different ways.
It is true that failure might manifest in different ways, but this possibly conflates not using the newest tech with failure, which isn't necessarily true. Back when the COVID tracing apps were being implemented, my country managed to mostly get it done with using a pretty old tech stack: some Ruby, some Node here and there, as well as OCI containers without anything like K8s operators or CRDs.
It worked fine, it scaled decently, there were no loud snafus in the media or glaring deficiencies. I personally got to write the homepage with a pretty boring tech stack: React with no hooks, Bootstrap (instead of something like Tailwind), Nginx and Node for some read-only API components and S3 for files: https://apturicovid.lv/#en
Though maybe the difference here was that it was a volunteer project by people who actually cared about what they were developing, instead of just getting a fat paycheck and padding their CVs (more about that below).
Sometimes you just work at a scale where you don't need millions of writes/reads per second, given that your country literally doesn't have enough citizens for that sort of a load. You also don't always need to explore something like CQRS, pub-sub and event driven design and so on. Dare I say it, it would have probably worked just fine with Apache, PHP, Varnish and jQuery as well.
I've seen some of the largest companies in the entire country succeed whilst running on somewhat dated monoliths, any outages being inconsequential to getting their business processes done. I've seen some others fail with microservices due to underestimating how complicated getting them into prod would actually be, especially with plenty of dated red tape around it. That said, there have also been monoliths failing and microservices succeeding, it's just that the newness of any particular approach/technology doesn't always equate success or failure.
This is situational, but that's my point - there are a lot of comparatively smaller projects and companies out there. Most people don't deal with the interesting sorts of problems that SV companies work with.
> You will still fall behind more agile organizations, but instead of your company going bankrupt, citizens will increasingly view the government as inept, loose trust, etc. A terrible enough digital infrastructure will eventually become a drag on your GDP and lower your standard of living relative to other places.
If we are talking about failure in particular, i mostly agree; that is actually a pretty good point!
However, once again, there is some nuance about it. In my country, the tax declaration system (https://eds.vid.gov.lv) has had a history of falling over on the day when you can submit your taxes or when under more severe load. And yet, everyone gets their stuff done regardless, even if they need to come back to it a day or two later, after seeing that it's overwhelmed with the load. There is little more impact apart from inconvenience.
In contrast, the e-health system of the country has had like a dozen million euros invested in it and still doesn't work properly [1][2]:
> In December, the availability of e-health was disrupted for seven days (with one exception - on working days), but for another five working days it did not actually work. For example, on December 7, none of the e-health services were available for more than four hours (4 h 13 min) during the working day. January looks a little better - the disruption is in six working days, but in February three days of e-health is disrupted, but for four days it can be said that the system does not work.
And yet, in regards to the failures of it, there is a lot of talk not of technological factors, but rather bad planning, changing requirements, bad development, bad testing and lot of overpromising, underdelivering and lots of filling their own pockets when they should have been working [3].
> "We are very worried. The situation is that the Ministry of Health has not learned to say what it wants. Different performers have designed the unknown, which has been said by various experts. They have designed on different platforms that are not compatible with each other, ”admitted Belēvičs. However, it is possible to "combine these incompatible parts on one payment axis, creating an opportunity for patients to pay co-payments for medicines and reimbursement for examinations and other health care services with a bank card". According to Belevich, this project is still to be saved, but it would need additional funding. So far, more than ten million lats have been spent on the project, but the minister did not specify the exact amount. It has already been reported that e-health computer systems have been developed but are not compatible with each other, according to the National Health Service responsible for the "e-health" project. The exchange of information between systems is not possible. Errors are currently being sought and corrected, but the project should be completed by mid-summer.
That last bit of text was written 7 years ago and the project never went anywhere. And no amount of ClickHouse, Go microservices or Kubernetes would have fixed that. It's important to recognize that some systems and domains matter more than others and that planning and the way something is developed might have a bigger impact than any choice of a particular set of technologies for it.
> What's funny about your quotes is that Kubernetes is now 8 years old, very mature, very capable, widely-used, well-understood, with lots of tooling and wide-spread know-how. It is "boring".
I fear that this isn't entirely true, just look at: https://k8s.af/
People still make the same mistakes that they did years ago and for many out there, there is nothing that Kubernetes gives them (of the features that they actually use) that Docker Swarm or Nomad wouldn't provide, both being more simplistic solutions.
Actually, the long Roblox outage a while ago [4][5] was caused by relying on Nomad and not expecting certain failure modes, so not even those are foolproof either.
> The outage lasted for 72 hours and 45 minutes, or just over 3 days, making it the longest outage in Roblox history.
> The root cause was due to two issues. Enabling a relatively new streaming feature on Consul under unusually high read and write load led to excessive contention and poor performance. In addition, our particular load conditions triggered a pathological performance issue in BoltDB. The open source BoltDB system is used within Consul to manage write-ahead-logs for leader election and data replication.
For Kubernetes specific issues, see the link above, but it's always the same story with complex pieces of software: especially if you just think that you're one of the large corps that have large Ops/DevOps departments but actually have just decided to use Kubernetes/Kafka/another solution without having the proper resources to keep it running successfully.
It is capable, it is mature, it has a lot of tooling (though a lot of it is sadly SaaS/PaaS money grab attempts), but it is not nearly as well understood as it should be and thus is too widely used, to the point where i've heard people unironically make the suggestion of: "Yeah, you should never build your own clusters, just pay one of the large corporations do to that for you."
It is getting more boring, thanks to things like K3s/k0s/MicroK8s, Rancher/Portainer, Lens/k9s, Helm and other lightweight distros and tools to make running it more feasible for a wide variety of deployments, but it's still too much for many. Just consider needing a separate node with >4 GB of RAM to act as the leader server for a cluster, when both Docker Swarm and Nomad both get by with a few hundred MB at most. While there are many benefits to orchestration (to the point of this being a game changer, as well as using containers and 12 Factor Apps for cloud native solutions), the resource requirements and usage are both examples of Wirth's law and have gone leaps backwards from where we were with systemd and Ansible.
To me, the sweet spot is still something like:
- local development: Docker (though Podman is cool, too)
- local development of multiple services: Docker Compose
- running containers on a single server: Docker Compose
- orchestrating services across multiple servers: Docker Swarm (with ingress being a regular container) and maybe Portainer
- more complex orchestration, if you really need it: K3s/RKE with Portainer/Rancher (which deal with the complexity nicely)
I don't think your strategies are so different – the proposal here is not to _not_ adopt new technologies, but rather to ensure that you consider and manage the risk in doing so (which is very sensible IMO).
Further most companies don't make money directly from their technology choices – they make money from the services they provide to customers (which in the vast majority of cases are different things).
> I'm generally a fan of this, but following this too closely will eventually kill your company.
But isn't that where innovation tokens come in - evaluate the risks of the technologies you're using and know when you're taking a risk
IMV too many projects decide to try the new hotness without this evaluation, I've witnessed re-writes in the latest JS framework cost a company millions in lost revenue, also seen product rewrites take years and not deliver something that was much better than before
Yes some teams can build create products on top off 'non-boring' technologies but also witness how many every day sites are build on old boring technologies such as Rails
My rule of thumb is this: For the domain you work in, you CAN use cutting-edge technology. For things outside the product domain, use standard (boring, time-tested) technology to hedge risk.
For example, when writing a DB, you might make use of a novel data structure, but don't use, for instance, an experimental parsing library.
From what I have gathered the recommendation to choose boring tech usually has this idea factored in already and is more of a conclusion than an aspiration.
What one engineer can operate confidently doesn't necessarily extend to the rest of the team, who will have to support that system if that engineer leaves or has to work on other projects.
The lowest common denominator on a team is boring.
React is a boring technologie for me by now and it was a great choice for my latest project. Many very mature libraries and excellent support all around.
I don’t think you should either choose boring technology or adopt shiny new technology . It’s always in the middle and what your appetite for risk and business and financial situation is . For a business that can take risks by all means you should adopt new technologies because that’s what the future is . For ones with less risk appetite like large hospitals or banks you want boring technology until the shiny new tech has become more mature and resolved initial kinks at which point you should switch over otherwise risk being obsolete .
It was written at the end of a decade long hype cycle when a lot of old ideas got replaced by new ones. A bunch of these new ideas (eg mongodb) went out of vogue, but a whole bunch simply got better and established.
At the same time, a lot of previously boring technology caught up, so we now got to the point where formerly non-boring technology got more stable and established, and boring technology got, eh, less boring.
Eg Java severely un-sucked itself as a language. And if you still don't like it, you can use Kotlin and still get a fantastic ecosystem, tooling, etc etc skipping all the reasons to choose boring tech. Postgres got all kinds of fancy new features, including indexable jsonb which lets it compete with lots of NoSQL DBs. And so on, and so forth.
On the non-boring side, Go, Elixir, Rust, Redis all became stable, dependable technology choices that really aren't at all as risky as they used to be in 2015. Is Java more boring than Elixir? Sure, but is the Elixir ecosystem so tiny that picking it is a major risk? Definitely not.
The gap between what used to be boring and not narrowed a lot. Of course there's still new non-boring tech, but somehow it all feels a bit less paradigm changing to me. Eg React turned front-end dev upside down. Vue and Svelte just iterate on its ideas a bit.
Sure there's still some good ideas here. Maybe think twice before building a web app in 100% Rust, wasm-compiled on the frontend to a webgl based custom UI. But I don't think that's the kind of way-out-there stuff the authors of this article had in mind.
> The gap between what used to be boring and not narrowed a lot. Of course there's still new non-boring tech, but somehow it all feels a bit less paradigm changing to me.
What about new tech that's boring by design? To me, that kind of feels why Go succeeded: it didn't attempt to solve all of the world's problems, merely become a relatively simple language that one can pick up and be productive in reasonably quickly, while also having a decent amount of batteries included.
Over the years, there have been relatively few major changes (generics come to mind, but those don't really break much old code at all) and it's remained somewhat stable/boring throughout the years.
Give devs interesting work by having them solve interesting problems. If the technology stack is the "interesting problem" then you are wasting this developer excitement on something less valuable than higher-level business problems. Go up the stack, get devs excited to work on those higher-level problems, and spend less of that expensive dev time on high-risk software that has questionable impact on those higher-level problems.
This is such an uninteresting take. It's in the same category as "all programming languages are the same". I wonder where this comes from. Are all operating systems the same? Are all file systems the same? Are all databases the same?
New tech generally tries to solve some problem. Maybe your project doesn't need that solution. Maybe you have been waiting for something to come along to solve that problem.
The problem, is that the problems these "new techs" try to solve are usually problems that are not generally faced, or try to bring a new approach to a more general problem with already accepted solutions.
Aside: Sorry to be blunt but this is such a dumb term that distracts from some of the important lessons in this talk. The author confuses "innovation" with "novelty", "niche", "general familiarity" and so on. Choosing existing solutions has nothing to do with innovation. The innovation already happened. You're just integrating with it.
But what about expertise, leverage, problem fit, cost, licensing, performance, bloat, implied workarounds, maintainability, community, attracting the right people and trust? What about simplicity?
I think the bottom line here is to choose mastery and depth over novelty and breadth. Being really good at using very few orthogonal tools is a good thing. Spending more time on the abstraction layers above and below you rather than switching between arbitrary choices too.
But these things have _nothing_ to do with how novel, niche or "innovative" a given tech choice is. That's just plain old conservatism, which can be an advantage or a disadvantage depending on what kind of work you're doing.
Choose the appropriate tools for the job. I hate these idiotic posts that examine a sliver of a domain and think they have the answers to all of programming. It’s just naïveté on display, and this site eats it up.
Later, I worked at a smaller company that let a young talent bring in a newer, more complex technology stack, made for solving problems at a scale they not only didn't have, but would never even aspire to reach. His reason was clearly that he wanted it on his resume; it took me a while to figure out that was his supervisor's reason for letting him do it. Both probably left soon after, leaving behind a higher maintenance load that would have helped them only if they reached a scale 1,000x bigger than there was any prospect of.
These two cases (and several others like them) have convinced me that it is possible to screw this up in either of two directions. No doubt there is a good rule of thumb to determine how to get it right, but I haven't found it yet. The best I know of is, to be aware that it is very possible to get this wrong in either direction.