The thing that is missed with this argument is that tech just enables the business.

If a company is boasting constantly about how it moved from X to Y, they either have too much money, or none at all. If they have the luxury of re-writing a core business system every 6 months, we can glean two things:

1) they have terrible leadership

2) their teams can't agree to support each other.

One thing that is really dangerous, is thinking that shipping _any_ code, is better than shipping the _right_ code. Its very simple to think that your teams are being productive, if the only measure is shipping code.

It soon becomes a circle of deploy-refactor-rearchtect-urghLegacy. You feel productive because you are constantly creating new and tools. But they are to do pretty much the same thing, but on a different platform.

You are correct to observe that having a "boring" stack requires lots of hard work. It also moves against the current "dump anything into prod, because, docker". Like a news paper, it requires planning, editing and a style guide, with enforcers and gate keepers.

In my resume I used to list a bunch of technologies. These days I write the outcome of my projects. Eg 'My team increased customer retention by 3%'.

Technology is a tool to solve a problem and all problems are people problems.

Ultimately, you need to have a balance between tech and talk as that's the job to translate the two.

Lean too far on the talk and you end up in management, to far on the tech and you're writing software no one wants.

I would like to throw my 2 cents in that some of these advances around "new" ways do lead to some good things. The focus on service discovery is something that is incredibly helpful even for older technologies.

Consul is something you can add to even a very old application and give it modern scaling features, simply because it has a plain old DNS interface.

Redis is similar for caching, it's advanced, the interface is so simple to use, and it's so easy to deploy and manage.

On the flip side, I'd like to add that I worked for a startup and we chose a lot of boring technologies because we had a job to get done, and they all just worked. :)

Not sure I agree with this perspective. Many of these companies are started by engineers or product managers who have seen the boring solutions not work for them. In some cases they either see it not work many times or see a future where other organizations get to that point and need a better solution. In digging into what these companies do it becomes clear that they aren't doing it just to push new tech, but maybe I'm the one who hasn't seen enough.

You mention k8s and related stuff isn't always the answer. Seems you think it's somewhat valuable? I'd like to hear what sort of tech you think is creating a bubble by being so useless! Certainly k8s can't be it, because for large companies the automation abilities of such a system are quite clear. Does it intro new problems, of course, and if they aren't well solved yet you'll have to think hard about the benefits of adopting The New Way, but to call this a bubble is hard to accept.

Many solutions are useful in a context, and were built with that in mind. My point is that much of the adoption of them is context-free. Eg. NoSQL solutions were largely about dealing with scalability challenges with SQL databases that most people didn’t have. Also the scalability has nothing to do with SQL per se, that was just marketing.

Kubernetes is a great piece of technology but it’s also hyped beyond the stratosphere. My point wasn’t Kubernetes about thoughtful adoption of Kubernetes in context, it was about buzzword bingo being played by those that want to use a set of newer technologies as weapons for their political battles or career aspirations. This requires active leadership to resist.

"bubble" has a few meanings, or interpretations, and one of them is definitely, in this context, "a technology becomes so popular it gets used for things it probably shouldn't have been used for".

I think the main reason why it gets used for things it shouldn't be used for is that engineers get all enthusiastic about using it, and look for a job that it can be used for. This is especially true when the tech in question is becoming a de-facto requirement in the industry and everyone needs to know how to use it to succeed at their next interview.

Hence the need for this presentation, which wouldn't be needed (or popular) if there weren't so many damn bubbles.

"Many of these companies are started by engineers or product managers who have seen the boring solutions not work for them."

Most of the time (not all, but almost all of the time), if a "boring solution" doesn't work for you, the problem is you, not the solution. There's a reason it is boring.

>if a "boring solution" doesn't work for you, the problem is you, not the solution

Were the people who hated their pagers and wanted cell phones idiots? All the people who were writing GUIs in C and debugging memory leaks...was the problem that they were shitty programmers, or is there something to be gained by spending more time on the business logic and less time on memory management?

It's healthy to see the shortcomings of current solutions, and to wonder if there is a better way. It's not healthy to chase shiny objects simply because they are shiny, or to massively complicate your tech stack because it helps marginally with a short-term problem.

> Were the people who hated their pagers and wanted cell phones idiots?

Tangential comment here. No they are not idiots, but I can tell you from experience (my team and I build and manage a wide area paging network supporting over 40000+ emergency services first responders over an area of 230,000 km²+) that there are still advantages to paging protocols over 3G/4G in certain circumstances.

Coverage is one of them. Sometimes the best tool for a particular job is the older one.

"Idiots?" "Shitty programmers?"

Have you tried some of the modern decaffeinated brands? Some of them taste almost as good as regular coffee.