4 ms·

The other side I see to this is that if I don’t refactor this code, who will? I guess that opens the debate to does the code actually need to be refactored? So

The other side I see to this is that if I don’t refactor this code, who will? I guess that opens the debate to does the code actually need to be refactored? Sometimes not, but I have a very hard time leaving a 2000 line function alone, or a class with many levels of unnecessary inheritance. What I’ve started to think is that there are people who get things done, and people who refactor. People who get things done ship code fast. The good ones know when to make trade offs of purity vs practicality. The bad ones write unmaintainable code. They tend to view programming as a job, and code quality as a burden. They may refactor and make unrelated improvements, but it’s uncommon. People who refactor still get things done, but most of their work have rabbit holes tacked on. They delivered a bug fix, but they also greatly improved the test suite and tooling. They tend to value purity, best practices, and might view programming as a craft/art. The good refactorers make the high value changes that are a net benefit to the team; they might care about cleaning up important parts of the code, improving developer experience, or adding test coverage to critical functions. The bad refactorers rewrite a bunch of code because it wasn’t pure, and the team, customers, and business have no observable effect from it. I think teams need both kinds of people on it. Too many doers will lead to fast progress at first, but eventually grind to a haunt. I felt this was a HUGE problem at my team in AWS, and a major factor of why I left. Too many refactorers is equally problematic. Your code will be of great quality, but velocity will be unacceptable for the business. I personally am a refactorer. probably more of a bad refactorer than good, but it’s something I’m working on. Maybe this is a rationalization for my behavior so that I believe it’s important, but my time at AWS shipping 3 features a year with a team of 16 says that code quality really does matter.

giansegato 4y ago
What you're saying and what the article is saying are two different things. The whole point of the article is not "Don't refactor code"; it's "Never fix a bug and refactor in the same pull request". It's a matter of focus and intentionality.
- gonehome 4y ago
  Yeah - it’s ship the bug fix, then do whatever refactoring. Just ship the bug fix first.
  - mobiuscog 4y ago
    And then the refactoring may never happen. 'Phase 2 never happens'
    - gonehome 4y ago
      Don’t do it at some later date, do it right after. Just ship the low risk fix first. Otherwise if you’re not careful phase 1 never happens either.
      - VBprogrammer 4y ago
        The obvious question in any organisation with a layer of project managers is how to explain that you've delivered the fix and you haven't moved on to fixing the next most important thing or adding some other new functionality. Yes, that's probably a sign of poor project management or organisational brokenness. But it's also probably the reality for most people.
      - iopq 4y ago
        The bug fix might be the high risk change, since it's a hack on top of a hack that you think might cancel each other out
  - mijoharas 4y ago
    I just mentioned it in this comment[0] but I disagree with this premise too since sometimes it's more work to fix the bug without the refactor: > It also misses the point that sometimes refactoring makes it _easier_ to fix the bug, and that a large part of fixing a bug is understanding exactly what's happening with the code, which refactoring can also make easier. https://news.ycombinator.com/item?id=32749390 https://news.ycombinator.com/item?id=32749390
  - iopq 4y ago
- shepherdjerred 4y ago
  You’re right. My comment is a bit of a tangent into the idea of “what if I just did the bug fix to skip refactoring”. I clicked on this article because it applies to me (I constantly yak shave), but I’m a bit disappointed with how terse it was.
xcambar 4y ago
> if I don’t refactor this code, who will? I have had this conversation yesterday, and the refactorer asked this very question. Here's my answer: The question is improperly formulated. With your behavioral patterns of immediate refactoring, the question seems to be: "if I don't refactor this code NOW, who will?". I'd say that if you don't refactor the code now, someone else, maybe future you, may refactor it later. Most sane companies will protect engineering from impulsive feature requests and will add them to the backlog for future consideration. I'm trying to instill the same protective mindset in my teams, and help them not do refactorings immediately but rather consider them as potential work as dedicated items in the sprints or so. Doing so, prioritizing becomes a natural part of the refactoring/tech debt/tech risks agenda, because we have an overview of the work to do globally.
- shepherdjerred 4y ago
  In my experience (three years, two companies, so not much) refactors are beyond last place for prioritization. Even my current company which does a great job of handling tech debt doesn’t track refactoring well. How would you even do it? Imagine how many tickets you would have about the things that need to be improved. I guess this is delving into queue theory and how the work queue is growing to infinity because there aren’t enough workers. I miss personal projects
  - xcambar 4y ago
    I don't know your company and projects but I weight these tasks as business risks, business opportunities and developer productivity.
Gigachad 4y ago
Personably I just allocate X% of my time to this kind of work and spend it on the most productive improvements. You don’t have to die on every hill you see. And if most people do this it results in a constant shift to something better while still achieving business goals.
- shepherdjerred 4y ago
  > You don’t have to die on every hill you see. I’m still trying to internalize this hah
Sakos 4y ago
Building on this, I see a lot of areas of code that are effectively untouchable because of how much energy would need to be invested to understand the code and its context before making a change. So if a change has to be made to fix a bug or add a required feature, it's done in the most low-impact way, which only makes the code that much harder to understand in the future. Meanwhile, I can't get refactor-only commits through because nobody wants the code to be touched unless absolutely necessary. We're in the middle of migrating a massive PHP codebase to Java. The code I'm talking about is newer Java code. In a few years, people will be wondering why the Java code is as much as a mess as the PHP code and, if I happen to still be around, my response will effectively be "I told you so" (in kinder, more productive terms). I've basically determined that my only option to ensure continued or improving code quality is to combine refactoring and bug fixes in the same merge request, while still keeping them in separate commits. That way whenever I touch a part of code for bug fixing or whatever else, I leave it behind in much better state than it was before.
- spion 4y ago
  > I've basically determined that my only option to ensure continued or improving code quality is to combine refactoring and bug fixes in the same merge request, while still keeping them in separate commits. That way whenever I touch a part of code for bug fixing or whatever else, I leave it behind in much better state than it was before. I agree, in practice I think this is the best option, with some kind of timebox for the improvements made. One thing I'd like to add is setting up some kinds of tests. If nothing else is available, E2E tests for the critical paths of the business are a good start. For (micro)services, getting API contract tests to work is also invaluable.
- rroot 4y ago
  Refactoring while bug fixing can be good. But depending on your metrics, it might be underappreciated and seen as time wasting. The guy the goes around blasting bugs like there's no tomorrow looks good to the boss. When he leaves someone will have to refactor his mess and that's wasting time again.

giansegato 4y ago

What you're saying and what the article is saying are two different things. The whole point of the article is not "Don't refactor code"; it's "Never fix a bug and refactor in the same pull request". It's a matter of focus and intentionality.

gonehome 4y ago
Yeah - it’s ship the bug fix, then do whatever refactoring. Just ship the bug fix first.
- mobiuscog 4y ago
  And then the refactoring may never happen. 'Phase 2 never happens'
  - gonehome 4y ago
    Don’t do it at some later date, do it right after. Just ship the low risk fix first. Otherwise if you’re not careful phase 1 never happens either.
    - VBprogrammer 4y ago
      The obvious question in any organisation with a layer of project managers is how to explain that you've delivered the fix and you haven't moved on to fixing the next most important thing or adding some other new functionality. Yes, that's probably a sign of poor project management or organisational brokenness. But it's also probably the reality for most people.
    - iopq 4y ago
      The bug fix might be the high risk change, since it's a hack on top of a hack that you think might cancel each other out
- mijoharas 4y ago
  I just mentioned it in this comment[0] but I disagree with this premise too since sometimes it's more work to fix the bug without the refactor: > It also misses the point that sometimes refactoring makes it _easier_ to fix the bug, and that a large part of fixing a bug is understanding exactly what's happening with the code, which refactoring can also make easier. https://news.ycombinator.com/item?id=32749390 https://news.ycombinator.com/item?id=32749390
- iopq 4y ago
shepherdjerred 4y ago
You’re right. My comment is a bit of a tangent into the idea of “what if I just did the bug fix to skip refactoring”. I clicked on this article because it applies to me (I constantly yak shave), but I’m a bit disappointed with how terse it was.

xcambar 4y ago

> if I don’t refactor this code, who will? I have had this conversation yesterday, and the refactorer asked this very question. Here's my answer: The question is improperly formulated. With your behavioral patterns of immediate refactoring, the question seems to be: "if I don't refactor this code NOW, who will?". I'd say that if you don't refactor the code now, someone else, maybe future you, may refactor it later. Most sane companies will protect engineering from impulsive feature requests and will add them to the backlog for future consideration. I'm trying to instill the same protective mindset in my teams, and help them not do refactorings immediately but rather consider them as potential work as dedicated items in the sprints or so. Doing so, prioritizing becomes a natural part of the refactoring/tech debt/tech risks agenda, because we have an overview of the work to do globally.

shepherdjerred 4y ago
In my experience (three years, two companies, so not much) refactors are beyond last place for prioritization. Even my current company which does a great job of handling tech debt doesn’t track refactoring well. How would you even do it? Imagine how many tickets you would have about the things that need to be improved. I guess this is delving into queue theory and how the work queue is growing to infinity because there aren’t enough workers. I miss personal projects
- xcambar 4y ago
  I don't know your company and projects but I weight these tasks as business risks, business opportunities and developer productivity.

Gigachad 4y ago

Personably I just allocate X% of my time to this kind of work and spend it on the most productive improvements. You don’t have to die on every hill you see. And if most people do this it results in a constant shift to something better while still achieving business goals.

shepherdjerred 4y ago
> You don’t have to die on every hill you see. I’m still trying to internalize this hah

Sakos 4y ago

Building on this, I see a lot of areas of code that are effectively untouchable because of how much energy would need to be invested to understand the code and its context before making a change. So if a change has to be made to fix a bug or add a required feature, it's done in the most low-impact way, which only makes the code that much harder to understand in the future. Meanwhile, I can't get refactor-only commits through because nobody wants the code to be touched unless absolutely necessary. We're in the middle of migrating a massive PHP codebase to Java. The code I'm talking about is newer Java code. In a few years, people will be wondering why the Java code is as much as a mess as the PHP code and, if I happen to still be around, my response will effectively be "I told you so" (in kinder, more productive terms). I've basically determined that my only option to ensure continued or improving code quality is to combine refactoring and bug fixes in the same merge request, while still keeping them in separate commits. That way whenever I touch a part of code for bug fixing or whatever else, I leave it behind in much better state than it was before.

spion 4y ago
> I've basically determined that my only option to ensure continued or improving code quality is to combine refactoring and bug fixes in the same merge request, while still keeping them in separate commits. That way whenever I touch a part of code for bug fixing or whatever else, I leave it behind in much better state than it was before. I agree, in practice I think this is the best option, with some kind of timebox for the improvements made. One thing I'd like to add is setting up some kinds of tests. If nothing else is available, E2E tests for the critical paths of the business are a good start. For (micro)services, getting API contract tests to work is also invaluable.
rroot 4y ago
Refactoring while bug fixing can be good. But depending on your metrics, it might be underappreciated and seen as time wasting. The guy the goes around blasting bugs like there's no tomorrow looks good to the boss. When he leaves someone will have to refactor his mess and that's wasting time again.