Ask HN: Does every software project require a refactor?

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.