[mariopt]

Words can not express my hate for this kind of articles.

Imagine working on a legacy codebase where the PM holds the dogma of refactoring being a bad thing and expecting you to do it wrong, even micro managing your PRs.

Most often than not, I do see projects suffering and coders actually resigning due to a lack of internal discussing about best practices, having space/time to test potential solutions, having Lead devs who resemble dictators quite well.

Let me guess, some PM wrote this article and they just want you to push the product asap by applying pressure and not allowing you ever to refactor. This is just a casual day in software development. I'm not surprised anymore when most web apps have silly bugs for years because it's gonna be a Jira ticket and a big discussion about..... one evil thing called refactor.

Several years ago I rewrote a full SaaS in about 3 months, it took another team 12 months with 5 devs. Guess which version made the investors happy, mine.

Bad refactoring is just a product of poor engineering culture.

[remus]

> Imagine working on a legacy codebase where the PM holds the dogma of refactoring being a bad thing and expecting you to do it wrong, even micro managing your PRs.

I don't think the article said that anywhere? It was just a list of some common things that can go wrong when refactoring, along with some examples.

[CRConrad]

> Let me guess, some PM wrote this article

Nah, judging from the ancillaries (domain name, links to other articles, ads, etc) of the article, it was some guy selling an "AI" code tool of some kind who wrote the article.

(Probably a tool with Magikal Refactoring Functionality built-in... For a price.)

[exe34]

more people just means more time spent trying to coordinate and in the limit, you spend all the time talking and none coding.