3 ms·

Yes, but things change over time, and there is rarely a chance to go back and refactor. Every time you introduce something new, or make some tech decision, it s

Yes, but things change over time, and there is rarely a chance to go back and refactor. Every time you introduce something new, or make some tech decision, it should be able to exist without needing to be re-written for a long time. If you are lucky enough to have some budget available for refactoring, it will probably be incremental, so choose choose things that can be adopted incrementally.

mqrs 6y ago
> there is rarely a chance to go back and refactor I wouldn’t say that this has been true in my experience. I’ve worked on multiple products that evolve over time and it often happens that a new feature touches on previously built features that can’t support all the behaviors of the new one, so then a refactor of the old code (at least some of it) is necessary. You can argue that doing so would require regression tests, but that’s why you automate those with a unit testing framework. This mindset of never modifying previously written code within reasonable and pragmatic boundaries is so rigid and anti-growth, I don’t even know how it came to be so popular within an industry that identifies so closely with innovation. That’s how you end up with putting band-aid solutions on top of each other and slowing down the agility of your teams over time.