5 ms·

Be Team C. Team C works like team A. However every time a feature ships, someone who knows that feature well immediately refactors the relevant code to remove

Be Team C. Team C works like team A. However every time a feature ships, someone who knows that feature well immediately refactors the relevant code to remove the prototype scaffolding. When code becomes static, an expert adds good quality comments. When a bug is found, it is recreated in a regression test prior to being fixed for good.

jokethrowaway 5y ago
The sad reality of tech companies is that there is little incentive or bonuses for improving the situation. You won't get a bonus for cleaning up the code or for rewriting rotten code. Hack at the code for 4 years, collect your options and leave the mess to someone else. To be honest, a hacky codebase written fast is not the worst codebase to deal with. The worst type is when someone had the time to overarchitect and overengineer things. Following references across 200 different files, tracing calls through hundreds of microservices. Graphql servers with complex resolver logic.
- gridspy 5y ago
  > The worst type is when someone had the time to overarchitect and overengineer things. I concur. Refactoring should be as much about removing unneeded abstraction and features as it is about adding same. > there is little incentive or bonuses for improving the situation. Yeah, I just can't seem to believe this in my soul. I just want to fix ugly code and can't stop myself. I get huge satisfaction from speeding up, tidying up or fixing up bad code. It doesn't help when management wants to minimize time spent on such tidy-up, especially when it's hurting our productivity to maintain it without fixing it.
  - wsc981 5y ago
    I try to sneak in refactoring with other tasks.
    - gridspy 5y ago
      I find the best method is: 1. Figure out what needs doing and what code you need to use 2. Refactor the code you're using until the new code or change is easy 3. Make the change 4. Tidy and document. Repeat I often also document during step 1, while I am trying to understand code and realise that comments are missing.
  - mbrodersen 5y ago
    Just do it. Don’t ask for permission. You will end up more productive not less.
    - jamesfinlayson 5y ago
      This - I've been doing this for years now and simpler code (both simpler logic and the removal of unused code) makes working on legacy codebases feel completely different.
      - mbrodersen 5y ago
        Yep exactly my experience. That combined with solid tests => I spend almost 100% of my time adding new features instead of staring at code and fixing bugs.
- jimbokun 5y ago
  4 years is a long time to suffer through inscrutable code.

jokethrowaway 5y ago

The sad reality of tech companies is that there is little incentive or bonuses for improving the situation. You won't get a bonus for cleaning up the code or for rewriting rotten code. Hack at the code for 4 years, collect your options and leave the mess to someone else. To be honest, a hacky codebase written fast is not the worst codebase to deal with. The worst type is when someone had the time to overarchitect and overengineer things. Following references across 200 different files, tracing calls through hundreds of microservices. Graphql servers with complex resolver logic.

gridspy 5y ago
> The worst type is when someone had the time to overarchitect and overengineer things. I concur. Refactoring should be as much about removing unneeded abstraction and features as it is about adding same. > there is little incentive or bonuses for improving the situation. Yeah, I just can't seem to believe this in my soul. I just want to fix ugly code and can't stop myself. I get huge satisfaction from speeding up, tidying up or fixing up bad code. It doesn't help when management wants to minimize time spent on such tidy-up, especially when it's hurting our productivity to maintain it without fixing it.
- wsc981 5y ago
  I try to sneak in refactoring with other tasks.
  - gridspy 5y ago
    I find the best method is: 1. Figure out what needs doing and what code you need to use 2. Refactor the code you're using until the new code or change is easy 3. Make the change 4. Tidy and document. Repeat I often also document during step 1, while I am trying to understand code and realise that comments are missing.
- mbrodersen 5y ago
  Just do it. Don’t ask for permission. You will end up more productive not less.
  - jamesfinlayson 5y ago
    This - I've been doing this for years now and simpler code (both simpler logic and the removal of unused code) makes working on legacy codebases feel completely different.
    - mbrodersen 5y ago
      Yep exactly my experience. That combined with solid tests => I spend almost 100% of my time adding new features instead of staring at code and fixing bugs.
jimbokun 5y ago
4 years is a long time to suffer through inscrutable code.