3 ms·

Since we’re at the topic of eloquence, might I add that horribly-written codebases are unbearable to work with during this time, or perhaps even during regular

by mqrs 6y ago

Since we’re at the topic of eloquence, might I add that horribly-written codebases are unbearable to work with during this time, or perhaps even during regular times for as long as the set up is remote. I get it that codebases inevitably rot over time, but the amount of rot can be mitigated by good dev practices such as unit testing, code reviews, best-effort (not perfect!) documentation, and standardizing dev practices. Dev teams that simply don’t care about code maintenance practices because the code “works” won’t be able to move fast enough during regular times, much less during a pandemic remote-setup scenario.

brailsafe 6y ago
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.

by mqrs 6y ago

brailsafe 6y ago

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.