"Rewriting something to reduce technical debt" is the kind of nuclear option you would use if you had money - or developer hours - to burn.

Technical debt is better managed through gradual refactoring as part of the normal development processes. Of course there's still going to be a struggle between taking time to maintain code quality and sales wanting the next feature yesterday, but it's a different argument than "we want to rewrite this in shiny new framework X because someone on Hacker News said so" (not that this exact argument will be used, of course).

Automation I'd see more as a sensible move, if it reduces costs in the long term. Again it may take a back seat to short term priorities, particularly when cash is short.

Yes, indeed, I agree with all your points. And in pretty much all cases I would opt for "gradual refactoring" (and hopefully with lots of tests before starting).

What's fun is when bitrot in the automation sets in. It's hard to gauge the long term liability of it.

> But I'd venture a guess that lots of organizations have to find that middle ground between building constantly vs remodeling / improving the foundation.

> I'm focusing a bit more on devops

Shiny object syndrome can affect all fields.

A dev story: One of the new projects at work is an invoice automation system. For whatever reason, the initial design called for Redis as a key value store, and pgsql for their relational data. Ops already supports a ton of services on a shoestring budget, and Redis isn't currently on the list. I only found out about it when I saw a PR documenting the dependencies; they're now researching whether Postgres's hstore is compatible with their needs. Unconstrained, it's easy to end up with lavish designs that spread ops too thinly.

An ops story: Containers is the big one some ops members won't be quiet about. AFAICT, it provides us no real advantage over VMs, and we're likely to deploy containers on top of openstack VMs anyways. Of course, we deploy a number of open source apps like Drupal, WordPress, and MoinMoin that would need to be re-architected to support things like immutable infrastructure. And it's not like the dev has time to support those, they'd be busy auditing and fixing their own software.

Very familiar with the dev story and if new technologies on the dev side make it into production, it's yet another new technology that the ops team needs to support. I can't imagine the gazillion things that one might need to know as an ops person. There definitely needs to be a balance and a negotiation between dev and ops on what can be supported and whether these new shiny objects really make a material impact.