The motor-control firmware module has grown increasingly tangled because Developers have repeatedly added quick fixes directly into existing functions rather than restructuring them, and even small new Product Backlog items now require touching many unrelated parts of the file, so which practice would most directly improve this over time?

When a module's internal structure no longer matches what it is being asked to do, even small changes end up rippling outward into unrelated parts of the code, which is a classic sign that the design has fallen behind the accumulated changes made to it. Refactoring — restructuring existing code without changing its external behavior — is the practice that keeps a design able to absorb new work cleanly, and it works best woven into the regular rhythm of delivering Product Backlog items rather than treated as a separate, occasional cleanup project. Freezing the module and starting a parallel file avoids confronting the tangled design directly and instead creates two versions of similar logic to maintain, which typically makes the overall system harder to reason about, not easier. Routing structural decisions through Product Owner approval misattributes accountability, since the Product Owner is responsible for product value and ordering, not the internal design of the code, which belongs to the Developers. Restricting the module to a single senior Developer creates a dangerous single point of failure and does nothing to fix the underlying tangle — it just narrows who has to deal with it. A useful check is to look at how many files or functions outside the module itself had to change for the last few small motor-control items — a consistently wide blast radius for small changes is the clearest signal that refactoring, not caution, is what's needed.