Refactoring is a code-smell

Refactoring is a changing the factoring. It is making change. A system which is changing all the times is not stable. This is a sign of a deeper issue. Refactoring is changing something that is bad to something else, therefore its a codesmell.

[juliep]

I love a good refactor when I can make something simpler, easy to understand, faster, etc. However I agree that refactoring AS your way of developing is a nightmare. Good design starts from making decisions on a high level viewpoint, not just doing whatever gets the job done. Fortunately at my job I was the one designing the codebase of our current applications so I was able to implement a solid structure that keeps refactoring to a minimum. We’re able to pretty much just follow the pattern and it works well.

[jethrolarson]

This is certainly a hot-take though not one I would want spread to other developers.

[ChrisAthanas]

I’ve brought up this issue before several times with senior engineers and managers and they always rebuff me and dismiss my suggestions outright

I’ve been let go of jobs due to it

Why Is a little bit of design up front such a dirty word?

[marco.garofalo]

Refactoring for the sake of refactoring has no value, and maybe can be considered a code smell in that particular case, BUT that's just a degenerate case so let's discuss what refactoring actually enables. I guess you are familiar with the concept of "making the change easy, then make the easy change", which translate into "change your system in order to accept the new behaviour but without changing the current one (i.e. refactoring), then add the new behaviour". This means that I can design my system to support the "now needs" not the "maybe later needs", this is because priorities in our backlog might change a lot due to external factors, so following YAGNI is a good way to avoid adding accidental complexity to our system, to support something that might NEVER come (i.e. deprioritised, no more valuable etc). then I can use refactoring techniques to move from the "old needs" to the "new needs" iteratively, moving the design to the open closed principle where appropriate. Also saying I can refactor later is not generally a bad thing, as mentioned before one of the best moments to do refactoring is prior to work on a new behaviour, because that's the "last responsible moment" to do so.

[ChrisAthanas]

Meh 7:57 open closed príncipe is overrated