5 ms·

Or sometimes it’s just when developers don’t like how something was implemented such as it’s OO and they believe it should be FP, or vice-versa. Or more annoyin

Or sometimes it’s just when developers don’t like how something was implemented such as it’s OO and they believe it should be FP, or vice-versa. Or more annoying, when something doesn’t use their favorite library but it has zero impact on the user. The question I always ask is what happens if we do nothing? Debt at 0% interest is obviously not a problem.

oriolid 6y ago
Developers refusing to work on the code as it is doesn't sound like 0% interest to me.
- jelling 6y ago
  That is not at all the scenario I described.
aeternum 6y ago
I see this very frequently, especially with newer developers. The code wasn't written using the paradigm they are familiar with or used at a previous company so they view the code as needing a refactor. Often the original paradigm was chosen for a reason and it becomes clear that the refactor was a step backwards. Any ideas on how to prevent this?
- rendall 6y ago
  I don't know that it's possible to prevent it, but include the coder's perspective in a team conversations about the project, standards and such If it's innocuous and they have a bee in their bonnet, consider letting them refactor on their own branch, and subject it to normal code review Recount the Parable of Chesterton's Fence Ask them if they are just bikeshedding Let them make low cost mistakes to learn cheap lessons, saving expensive lessons later
- habitue 6y ago
  > especially with newer developers My experience is junior and senior developers fall for this. > Often the original paradigm was chosen for a reason True, but the reason is often: - we didn't understand the problem domain as well when we wrote it - it was written this way because it needed to integrate with a system that existed at the time but no longer does - there was a guy who was really into X and he insisted on writing it this way. He no longer works here and no one wants to touch that code - It was written by an intern - It was written by a bad software developer (you're not morally bad for being a bad software developer, but they are real, and they write code) - It was written as a prototype and was supposed to be thrown out - It was written by me, and the fact that you want to rewrite it makes me feel bad > Any ideas on how to prevent this? Exploratory refactoring is actually a really good way to understand code deeply. Sometimes the refactor is bad and your throw it out, that's ok, you learned something. This applies to developers refactoring code, they learn the reasons for things as they rewrite it.
- conradludgate 6y ago
  In my team, we always discuss refactors in a large meeting with all the developers. We plan and propose and discuss the prior reasons as to why things were written this way and why it would benefit from being that way, and we might even do some experimentation before going with a full refactor
- hindsightbias 6y ago
  There was a time when new hires spent years or more doing support and learning all the codebase. I got to learn how very interesting and complex systems (from a space program to a Unix kernel) worked. I got to see what brilliant, pedestrian and bad code looked like. Now, new hires need to be given the new features so they’re happy and can rush out and create new technical debt from day one.
alacombe 6y ago
Just as if we were machines capable to blindly pick up where other machines left off and follow the same... programming (quite literally). Quite the contrary.

oriolid 6y ago

Developers refusing to work on the code as it is doesn't sound like 0% interest to me.

jelling 6y ago
That is not at all the scenario I described.

aeternum 6y ago

I see this very frequently, especially with newer developers. The code wasn't written using the paradigm they are familiar with or used at a previous company so they view the code as needing a refactor. Often the original paradigm was chosen for a reason and it becomes clear that the refactor was a step backwards. Any ideas on how to prevent this?

rendall 6y ago
I don't know that it's possible to prevent it, but include the coder's perspective in a team conversations about the project, standards and such If it's innocuous and they have a bee in their bonnet, consider letting them refactor on their own branch, and subject it to normal code review Recount the Parable of Chesterton's Fence Ask them if they are just bikeshedding Let them make low cost mistakes to learn cheap lessons, saving expensive lessons later
habitue 6y ago
> especially with newer developers My experience is junior and senior developers fall for this. > Often the original paradigm was chosen for a reason True, but the reason is often: - we didn't understand the problem domain as well when we wrote it - it was written this way because it needed to integrate with a system that existed at the time but no longer does - there was a guy who was really into X and he insisted on writing it this way. He no longer works here and no one wants to touch that code - It was written by an intern - It was written by a bad software developer (you're not morally bad for being a bad software developer, but they are real, and they write code) - It was written as a prototype and was supposed to be thrown out - It was written by me, and the fact that you want to rewrite it makes me feel bad > Any ideas on how to prevent this? Exploratory refactoring is actually a really good way to understand code deeply. Sometimes the refactor is bad and your throw it out, that's ok, you learned something. This applies to developers refactoring code, they learn the reasons for things as they rewrite it.
conradludgate 6y ago
In my team, we always discuss refactors in a large meeting with all the developers. We plan and propose and discuss the prior reasons as to why things were written this way and why it would benefit from being that way, and we might even do some experimentation before going with a full refactor
hindsightbias 6y ago
There was a time when new hires spent years or more doing support and learning all the codebase. I got to learn how very interesting and complex systems (from a space program to a Unix kernel) worked. I got to see what brilliant, pedestrian and bad code looked like. Now, new hires need to be given the new features so they’re happy and can rush out and create new technical debt from day one.

alacombe 6y ago

Just as if we were machines capable to blindly pick up where other machines left off and follow the same... programming (quite literally). Quite the contrary.