Yes. Continuously.

There's 3 times to refactor:

1. When you're trying to add a new feature ("prepare").

2. When the new functionality has been added ("tidy").

3. When you're trying to understand the code ("clarify").

The problem is when refactoring is seen as a separate activity from coding. It shouldn't be: it is a _part_ of the coding activity.

Because the requirements change, the performance characteristics change, and the people change. But even if none of that was true the technology landscape changes (e.g. Angular 1.x to Angular 2.x+).

If you show me a project that couldn't benefit from a refactor, then you're showing me a project that is effectively EOL sooner or later.

The words software project are doing a lot of work in this sentence.

Refactoring is a function of scope and scope violations. When things violate their scope and use global state, the end result is brittle hard to change and even harder to test code.

Many scopes will need to be refactored over time and if elements of a software project are tightly coupled that will mean refactoring the project rather than a module or a component.

As the sins of short term thinking accumulate so too does the daily pain of working on a project until people start to want to factor out their components (in the worst case this is called micro-services), or do a complete re-write.

I think refactoring should always be done with any change to fix scoping problems (removing usage of global state) and a complete refactor is to be reserved for core architecture problems and scaling issues.

The most sane approach is to use something like bazel to start limiting what can depend on what where, which will slowly start to decouple components, likely via forcing dependency injection.

Once you have pressure pushing in the direction of lower complexity (via enforcing limitations) rather than increasing complexity, a lot of problems that seem untenable before become approachable.

Except for a small set of programs where the specification is completely defined (think mathematics) every software system evolves according to a well-known life cycle. It changes continuously to address new and evolving external world requirements, its structure degrades and becomes more complex and difficult to maintain unless work is done to maintain or reduce it.

Because you phrased it as "eventual refactoring", I'm going to take your question to mean that at some point in the lifecycle the codebase becomes too complex and degraded for a team to work on. At that point, the choice is to either fix it or replace it.

But well-maintained codebases undergo continual refactoring, which counters the decay and trend towards excess complexity. Look at things that have been in use for a long time. The Apache http server has been around since 1995, with only the release 2.0 introducing wide-ranging changes. Linux began in 1991.

In short, if the team, for whatever reason, neglects the effort to maintain the quality of the codebase, then yes, if it continues to be in use, it will need a comprehensive refactoring, or replacement.

Yes. Other things aside, there is the concept of "software rot" :). Look it up.

Require? No. Could use one? Yes. Every project could use refactoring, at all stages.

"Plan to throw one away, you will anyhow" - Fred Brooks

not just one. that's insane. plan on refactoring everything a little bit at a time, always.