4 ms·

Along similar lines, most developers are afraid of deleting code. They would rather pile on more code to try to add a parallel system or patch around a problem

by nayuki 6y ago

Along similar lines, most developers are afraid of deleting code. They would rather pile on more code to try to add a parallel system or patch around a problem instead of fixing or deleting the problem itself.

infogulch 6y ago
"refactor" is a trigger word for my tech lead now. It's exhausting when every attempt to improve the codebase is a battle. When I'm tasked with fleshing out the third bugfix story for a feature that I refactored in 30 minutes 2 months ago, but the PR for it which demonstratively would have solved all of them is still lying on the floor... a little part of me dies inside.
- fshbbdssbbgdd 6y ago
  I try to avoid calling anything a refactor. I just describe it as part of the fix. Similarly I never try to convince management that I need time to improve code quality... I just do it to code that I’m touching. I think people who don’t know the details have the (often correct) heuristic that work that doesn’t deliver incremental results is just an excuse to waste time / sandbag, so I just don’t bother trying to convince about the ROI.
  - infogulch 6y ago
    I tried that until they reviewed it (they're a required reviewer for all PRs...) and forced me to split the refactor into a separate PR and let it sit there for 2 months before asking me to delete it. This occurred multiple times.
jandrese 6y ago
Most people don't add more code just for fun. If you're deleting something you had better have a solution to whatever problem that code was solving in the first place. It definitely makes sense to delete code in some cases, but most of the time the solution requires the addition of code. This makes sense, the size of a program doesn't tend towards zero over time. They tend to grow as new features are necessary and yet the old features can't be retired without causing disruption.
- Spartan-S63 6y ago
  Additionally, time pressure constraints often prevent refactoring and other code-minimizing opportunities. Usually, there isn't enough time given to paying down tech debt or refactoring swaths of code to allow for the overall reduction in line count while delivering new features. That reality, though, isn't always possible, and software will always trend towards larger line counts and more complexity.
pessimizer 6y ago
I'm the opposite. Every time I look at my old code for more than 5 minutes, it gets shorter.
- nayuki 6y ago
  Me too - I enjoy reviewing my existing work, and slowly over months and years with fresh eyes, I modify my code to be shorter or clearer. Some evidence exists in the history of https://github.com/nayuki/Nayuki-web-published-code https://github.com/nayuki/Nayuki-web-published-code , for example https://github.com/nayuki/Nayuki-web-published-code/commits/master/avl-tree-list/avltreelist.rs https://github.com/nayuki/Nayuki-web-published-code/commits/... . It's funny you call yourself "pessimizer", because you seem to be good at optimizing.
cle 6y ago
This fear is well-founded. Changing a system is a lot riskier than leaving it alone and building things around the periphery. Changing it requires a deep understanding of the implications of the changes, the impact on consumers/clients/other systems, etc. Doing that continuously does accrete complexity. But there is often a higher cost to fixing a problem rather than working around it.
- lukifer 6y ago
  While you’re completely correct, I’ve also observed an anti-pattern where people become afraid to touch load-bearing code if it “works”, compounding over time into a brittle codebase and piles of hacks to work around shortcomings in infrastructure. Assuming it meets the risk/cost/reward trade-offs, I’ve found it’s preferable to rip the bandaid off and refactor ASAP, rather than allowing “fear-driven development” to take root. (Obviously, a robust test suite greatly lessens the risks.)
  - cle 6y ago
    I completely agree, and I do the same thing too. If there's something that people are scared to touch, I immediately want to change something fundamental in it so we can get un-scared of it. I'd rather have a controlled demolition than a "rapid unscheduled disassembly".
    - lukifer 6y ago
      Superb analogy!
mabbo 6y ago
Far worse, they'll comment out no-longer-needed code. We have git! You can get it back anytime you want! Just delete it!
- lessthanseventy 6y ago
  If it is deleted instead of commented out I would have to know it used to be there in the first place to track it down in the git history.
  - simmerup 6y ago
    It quickly becomes so out of date that the commented out code provides no use to the reader anyway.
    - deleted 6y ago
      [deleted]
- darkwizard42 6y ago
  commented out code helps any future developer either heed a past warning or learn from a past example. I think there are uses to commenting vs. deleting
Trufa 6y ago
This reminds me of one of my favorite HN entries: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction >> Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.

by nayuki 6y ago

infogulch 6y ago

"refactor" is a trigger word for my tech lead now. It's exhausting when every attempt to improve the codebase is a battle. When I'm tasked with fleshing out the third bugfix story for a feature that I refactored in 30 minutes 2 months ago, but the PR for it which demonstratively would have solved all of them is still lying on the floor... a little part of me dies inside.

fshbbdssbbgdd 6y ago
I try to avoid calling anything a refactor. I just describe it as part of the fix. Similarly I never try to convince management that I need time to improve code quality... I just do it to code that I’m touching. I think people who don’t know the details have the (often correct) heuristic that work that doesn’t deliver incremental results is just an excuse to waste time / sandbag, so I just don’t bother trying to convince about the ROI.
- infogulch 6y ago
  I tried that until they reviewed it (they're a required reviewer for all PRs...) and forced me to split the refactor into a separate PR and let it sit there for 2 months before asking me to delete it. This occurred multiple times.

jandrese 6y ago

Most people don't add more code just for fun. If you're deleting something you had better have a solution to whatever problem that code was solving in the first place. It definitely makes sense to delete code in some cases, but most of the time the solution requires the addition of code. This makes sense, the size of a program doesn't tend towards zero over time. They tend to grow as new features are necessary and yet the old features can't be retired without causing disruption.

Spartan-S63 6y ago
Additionally, time pressure constraints often prevent refactoring and other code-minimizing opportunities. Usually, there isn't enough time given to paying down tech debt or refactoring swaths of code to allow for the overall reduction in line count while delivering new features. That reality, though, isn't always possible, and software will always trend towards larger line counts and more complexity.

pessimizer 6y ago

I'm the opposite. Every time I look at my old code for more than 5 minutes, it gets shorter.

nayuki 6y ago
Me too - I enjoy reviewing my existing work, and slowly over months and years with fresh eyes, I modify my code to be shorter or clearer. Some evidence exists in the history of https://github.com/nayuki/Nayuki-web-published-code https://github.com/nayuki/Nayuki-web-published-code , for example https://github.com/nayuki/Nayuki-web-published-code/commits/master/avl-tree-list/avltreelist.rs https://github.com/nayuki/Nayuki-web-published-code/commits/... . It's funny you call yourself "pessimizer", because you seem to be good at optimizing.

cle 6y ago

This fear is well-founded. Changing a system is a lot riskier than leaving it alone and building things around the periphery. Changing it requires a deep understanding of the implications of the changes, the impact on consumers/clients/other systems, etc. Doing that continuously does accrete complexity. But there is often a higher cost to fixing a problem rather than working around it.

lukifer 6y ago
While you’re completely correct, I’ve also observed an anti-pattern where people become afraid to touch load-bearing code if it “works”, compounding over time into a brittle codebase and piles of hacks to work around shortcomings in infrastructure. Assuming it meets the risk/cost/reward trade-offs, I’ve found it’s preferable to rip the bandaid off and refactor ASAP, rather than allowing “fear-driven development” to take root. (Obviously, a robust test suite greatly lessens the risks.)
- cle 6y ago
  I completely agree, and I do the same thing too. If there's something that people are scared to touch, I immediately want to change something fundamental in it so we can get un-scared of it. I'd rather have a controlled demolition than a "rapid unscheduled disassembly".
  - lukifer 6y ago
    Superb analogy!

mabbo 6y ago

Far worse, they'll comment out no-longer-needed code. We have git! You can get it back anytime you want! Just delete it!

lessthanseventy 6y ago
If it is deleted instead of commented out I would have to know it used to be there in the first place to track it down in the git history.
- simmerup 6y ago
  It quickly becomes so out of date that the commented out code provides no use to the reader anyway.
  - deleted 6y ago
    [deleted]
darkwizard42 6y ago
commented out code helps any future developer either heed a past warning or learn from a past example. I think there are uses to commenting vs. deleting

Trufa 6y ago

This reminds me of one of my favorite HN entries: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction >> Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.