The "When touching it is the right call" is the tricky part, because it contains this very subjective exception: "Every new feature costs three times what it should because of the design, and you can show the trend."

I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.

Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)

▲

stingraycharles 2 hours ago | parent | next [-]

Everything about all this has always been subjective, which is what separates good engineers from bad ones. Bad ones do refactorings that add very little value, good ones do it the right way, at the right time.

It’s also why, as you become older, the more senior you are the more you start to appreciate “boring” solutions and avoid fancy abstractions. It almost always serves the business much better.

▲

bbsnly 3 hours ago | parent | prev | next [-]

I really like your comment about "re-architecture". I 100% agree with you.

	▲	atq2119 2 hours ago \| parent [-]
		To expand on this, I've found that often, the best way to make a change is in two steps: First, make the change easy (the re-architecture). Second, make the change that is now easy. My best software development experiences have been in cultures where this way of working was common. It is a shame that these cultures are not more widely spread; and I mostly blame GitHub: the lack of good support for stacked PRs or patch series or whatever you want to call it makes it harder than it should be to work in this way.

▲

malux85 2 hours ago | parent | prev [-]

> I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.

To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (inability to change is also another red flag).

There is a small chance that there's strong logical reasons for a desire to fundamentally change an underlying technology, but the comment above says they "simply refused to become competent in ....... that the system is built on" and as a ex-google senior engineer of 20 years, I can 100% confidently say that the first step to large scale refactor is to understand and be competent in the existing system!

	▲	bluefirebrand an hour ago \| parent [-]
		> this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring Agree that it's almost certainly a mistake in hiring but strongly disagree that it's a negative signal in the employees mindset Being specialized in one area is actually a good thing for many people and many roles. It's actually kind of bullshit that software companies expect everyone to be a generalist nowadays Having strong preferences about the tech you like to use and the way you like to build is fine. Find the employers with projects and teams that match your preferences rather than trying to crowbar yourself into everyone else's preferences