4 ms·

Turning 50 this year, writing code for living, and could not agree more. I used to think all must be re-written and refactored. "Old crap must go". "I can do it

Turning 50 this year, writing code for living, and could not agree more. I used to think all must be re-written and refactored. "Old crap must go". "I can do it better". But then one realizes the rewritten system is "crap" to someone else soon. Learning existing system is harder than to create something seemingly equivalent that author understands well. For some time at least.

leetrout 3y ago
My measuring stick is how much the team can understand what is happening. When the team at large cannot move through the codebase and effectively make changes then it is time to make changes. If the code is on the back burner and only receiving maintenance then no need to mess with it. But active feature development? Teams need to have a grasp on it and have a way to get a mental model of what is happening.
- lazyasciiart 3y ago
  A team that can’t understand what the code does now is not going to write a functional replacement any time soon.
  - whstl 3y ago
    In a dysfunctional company where "the code is the documentation"? Yeah. If there are knowledgeable people to lead the process, and the transition is done appropriately: it is 100% possible and I have done multiple times in my career. The burden on rewriting shouldn't lie in developers alone. And before someone quotes Spolsky: not every software is Netscape Navigator.
- gertlex 3y ago
  Corollary: If the change is going to make it harder to effectively make changes (and figure out changes that need to be made, i.e. manual troubleshooting), it's probably a bad change. (this corollary might be most applicable in robotics?; dealing with the fallout of kubernetes being forced onto robots by cloud-oriented folks)
  - leetrout 3y ago
    Wow, I am sorry for your pain and suffering. I am not anti-k8s, I get it, I get why people like it. But it's just so much complexity for so little payoff in many cases where you don't need the overhead.
codelobe 3y ago
I never refactor for the purpose of refactoring. If I can do things better, and I usually can, it's because I have a more performant higher level algorithm or set of low level optimization strategies to apply. I agree, Those API organizers are just creating future crap for others. However, objective benchmarks showing my changes yield 10 to 100 thousand times quicker execution than the old method mean the legacy code was crap... Legacy being crap is not always the fault of devs. Back on Z80 and similar, before execution caches were expansive and expensive to invalidate, the short circuiting && and || bool operators made sense. Now that invalidating the CPU instruction cache with a jump is far more expensive than just running the ops these short circuits are trying to avoid, it is better to just use bitwise | or & instead of boolean || or && unless there are needed side-effects (really should make the conditional evaluations into proper branches [if statements] anyway, if only for clarity). Benchmark it and see. C is stuck doing LOTS of old and busted style logic, and coders imagine their compiler is doing a lot of magic voodoo under the hood that simply isn't happening. There's loads of compiler optimization hype. Sometimes the hardware or platform just shifts underneath Good Code and turns it into Crap Code.
TylerE 3y ago
As ever, the greatest programmers are fundamentally lazy. I hate writing code. I endeavor to do as little of it as possible. Solving problems? Sure, love to. But slogging out LOC for the sake of it? Hard pass. Even as a teen that never really appealed to me.

leetrout 3y ago

My measuring stick is how much the team can understand what is happening. When the team at large cannot move through the codebase and effectively make changes then it is time to make changes. If the code is on the back burner and only receiving maintenance then no need to mess with it. But active feature development? Teams need to have a grasp on it and have a way to get a mental model of what is happening.

lazyasciiart 3y ago
A team that can’t understand what the code does now is not going to write a functional replacement any time soon.
- whstl 3y ago
  In a dysfunctional company where "the code is the documentation"? Yeah. If there are knowledgeable people to lead the process, and the transition is done appropriately: it is 100% possible and I have done multiple times in my career. The burden on rewriting shouldn't lie in developers alone. And before someone quotes Spolsky: not every software is Netscape Navigator.
gertlex 3y ago
Corollary: If the change is going to make it harder to effectively make changes (and figure out changes that need to be made, i.e. manual troubleshooting), it's probably a bad change. (this corollary might be most applicable in robotics?; dealing with the fallout of kubernetes being forced onto robots by cloud-oriented folks)
- leetrout 3y ago
  Wow, I am sorry for your pain and suffering. I am not anti-k8s, I get it, I get why people like it. But it's just so much complexity for so little payoff in many cases where you don't need the overhead.

codelobe 3y ago

I never refactor for the purpose of refactoring. If I can do things better, and I usually can, it's because I have a more performant higher level algorithm or set of low level optimization strategies to apply. I agree, Those API organizers are just creating future crap for others. However, objective benchmarks showing my changes yield 10 to 100 thousand times quicker execution than the old method mean the legacy code was crap... Legacy being crap is not always the fault of devs. Back on Z80 and similar, before execution caches were expansive and expensive to invalidate, the short circuiting && and || bool operators made sense. Now that invalidating the CPU instruction cache with a jump is far more expensive than just running the ops these short circuits are trying to avoid, it is better to just use bitwise | or & instead of boolean || or && unless there are needed side-effects (really should make the conditional evaluations into proper branches [if statements] anyway, if only for clarity). Benchmark it and see. C is stuck doing LOTS of old and busted style logic, and coders imagine their compiler is doing a lot of magic voodoo under the hood that simply isn't happening. There's loads of compiler optimization hype. Sometimes the hardware or platform just shifts underneath Good Code and turns it into Crap Code.

TylerE 3y ago

As ever, the greatest programmers are fundamentally lazy. I hate writing code. I endeavor to do as little of it as possible. Solving problems? Sure, love to. But slogging out LOC for the sake of it? Hard pass. Even as a teen that never really appealed to me.