[hinkley]

You know you can acknowledge a problem and that doesn't mean you have to solve it this very instant, right? It's not a matter of either dropping everything or gaslighting people^W^W dismissing the issue as trivial. There are other choices. Many other choices.

If you don't think the problems people are bringing you have merit, then they won't bring you any problems at all, even when they have merit. Suck it up and realize that you're going to have to allocate a little bit of time on "good problems to have" (if this is our biggest problem right now, things are going very well) or you'll either introduce latency into your early warning system or shut it down entirely.

> if the problem boils down to "this architecture isn't pure enough"

Then the problem is that your coworkers think that purity is a magic shield that will protect them from all ills, which is a bigger problem. You still need to hear it, even if you don't like it.

Honestly though a lot of times when I find myself at odds with someone they try to dismiss my concerns as matters of purity when what I'm really complaining about is the smoke that's coming out of the machine (or the team's ears) because they're riding it too hard. Sharpening the saw isn't aesthetics. Preventing wear and tear isn't some white tower bullshit. It's about keeping something in the tank for the next problem we don't know we have yet. People who don't believe in burnout are doomed to create it, usually in others.

[boredtofears]

People think they’re designing a spaceship, when in reality they’re building something closer to IKEA furniture.

YAGNI applies to a lot more than most people think it does.

[hinkley]

Targets of opportunity are problems that have a distinct value in being solved which is less than the naive cost of fixing it.

Not the actual cost of fixing it, the 'drop everything and work on it now' cost, adjusted for Murphy's law. These are often the sort of 'nice to haves' that come out to 3 months of work, which nobody is going to approve unless a customer is actively yelling in their face about it. And sometimes not even then.

Refactoring is Make the Change Easy, Then Make the Easy Change. If you don't know what your targets of opportunity are, because you have some misguided notion that you can't [have an adult conversation about the state of things](https://www.jimcollins.com/concepts/confront-the-brutal-fact...) without tender egos being hurt, then instead of moving toward any of the horizons you'll just sail in a big circle while people keep trying to get you to venture farther afield.

[boredtofears]

The problem I often see is in the evaluation of the naive cost of fixing it versus the actual probability your target of opportunity will become a legitimate design consideration. The naive cost almost always is large but the probability your target of opportunity will be necessary is often small or miniscule. It's easy to try to cover all your bases and write something in an unnecessarily flexible way when a concrete implementation would have solved the immediate requirements succinctly and very likely may not to be touched again for years (if ever again).