2 ms·

Not really. When each PHP page was copy pasted and slightly modified, I had to manually search to fix each bug and fix it in EVERY instance. Are you going to t

by iopq 4y ago

Not really. When each PHP page was copy pasted and slightly modified, I had to manually search to fix each bug and fix it in EVERY instance. Are you going to tell me that this kind of tech debt doesn't affect my time to fix the bug? I could have done it once, now I have to hunt for 5+ instances of it. Am I just complaining or did doing the original development in a lazy way directly impact my time to complete the task? I could have recorded the exact amount between the original bug fix and finally fixing the last instance of the bug to quantify how much time lazy coding cost me. It may have taken the same amount of time to write the original pages with an extendable component that only has one copy and takes arguments to create all the variations we need. But in the end we'd have fewer lines of code to maintain in the future and that's also an objective metric.

hamandcheese 4y ago
On the flip side, change is far more risky when it affects many callers rather than once page. Whatever time you “wasted” fixing multiple pages might be instead spent validating that the single fix doesn’t produce any unintended consequences. Simple duplication is probably the least bad form of tech debt I can imagine.
- iopq 4y ago
  You have to test all of the affected pages anyway the real horror is they have slightly different version since they already had other changes done to them, and I have to understand whether I should merge the functionality, keep it different, etc. when I have multiple callers it's going to be the same unless you pass in an argument, so that change is self-documenting since it signifies intent
resonious 4y ago
I think it's pretty easy to come up with a counter argument like "hey what if I want to change the code for this one page and not the others? well, good thing each page has its own separate code!" If the code in question was shared, this person would have to spend time thinking about whether to add a boolean flag to the shared function, create a new function, or what-have-you. And I can see other comments here saying that boolean flags are also tech debt. For your scenario, I completely agree that the decision to not share code lead to you spending more time. We can be objective about time spent for specific scenario A with codebase B, but we cannot enumerate all scenarios and all codebases and so it's quite hard to ask what's the expected value for "damage done" by a particular style of programming.
- iopq 4y ago
  Boolean flag is also a design that doesn't scale to multiple decisions. You should get used to designing things in a way that separates those concerns. Why does page A need functionality in this manner and page B needs a slightly different one? It's because they do similar things, but there's a difference there somewhere. Instead of copy pasting from page A and changing it, you should have a function that does the same things from page A and B, and then combining that partial result into the different pages in the way that you want. The function that does the same task for the pages can then be fixed for both pages if it has a bug in it. If you copy/paste then inevitably the person working on it will forget to find and fix one of the versions. But even if you end up spending a little more time to prevent code duplication than just copy/pasting, it STILL yields benefits in the lower maintenance cost since people will spend less time reading and understanding the code. Your codebase will have fewer lines of actual code, which is a win by itself, which you can quantify. You won't be able to measure the time each person will waste re-reading identical code to make sure it's actually identical (or worse, trying to see WHY it's not identical), but it's always a cost if you're working with this code. The only reason not to touch it if it's already perfect and won't be changed. But usually I will start on this refactor when I do have a requirement (it already has a bug, or I need to change functionality)
mmcnl 4y ago
Calling this tech debt will get you nowhere. Instead you could just explain the alternatives: what happens if we do this, what happens if we don't? If we do <X> productivity will increase by <Y> so that users will experience <Z>. Much clearer than simply saying "tech debt > refactor".

by iopq 4y ago

hamandcheese 4y ago

On the flip side, change is far more risky when it affects many callers rather than once page. Whatever time you “wasted” fixing multiple pages might be instead spent validating that the single fix doesn’t produce any unintended consequences. Simple duplication is probably the least bad form of tech debt I can imagine.

iopq 4y ago
You have to test all of the affected pages anyway the real horror is they have slightly different version since they already had other changes done to them, and I have to understand whether I should merge the functionality, keep it different, etc. when I have multiple callers it's going to be the same unless you pass in an argument, so that change is self-documenting since it signifies intent

resonious 4y ago

I think it's pretty easy to come up with a counter argument like "hey what if I want to change the code for this one page and not the others? well, good thing each page has its own separate code!" If the code in question was shared, this person would have to spend time thinking about whether to add a boolean flag to the shared function, create a new function, or what-have-you. And I can see other comments here saying that boolean flags are also tech debt. For your scenario, I completely agree that the decision to not share code lead to you spending more time. We can be objective about time spent for specific scenario A with codebase B, but we cannot enumerate all scenarios and all codebases and so it's quite hard to ask what's the expected value for "damage done" by a particular style of programming.

iopq 4y ago
Boolean flag is also a design that doesn't scale to multiple decisions. You should get used to designing things in a way that separates those concerns. Why does page A need functionality in this manner and page B needs a slightly different one? It's because they do similar things, but there's a difference there somewhere. Instead of copy pasting from page A and changing it, you should have a function that does the same things from page A and B, and then combining that partial result into the different pages in the way that you want. The function that does the same task for the pages can then be fixed for both pages if it has a bug in it. If you copy/paste then inevitably the person working on it will forget to find and fix one of the versions. But even if you end up spending a little more time to prevent code duplication than just copy/pasting, it STILL yields benefits in the lower maintenance cost since people will spend less time reading and understanding the code. Your codebase will have fewer lines of actual code, which is a win by itself, which you can quantify. You won't be able to measure the time each person will waste re-reading identical code to make sure it's actually identical (or worse, trying to see WHY it's not identical), but it's always a cost if you're working with this code. The only reason not to touch it if it's already perfect and won't be changed. But usually I will start on this refactor when I do have a requirement (it already has a bug, or I need to change functionality)

mmcnl 4y ago

Calling this tech debt will get you nowhere. Instead you could just explain the alternatives: what happens if we do this, what happens if we don't? If we do <X> productivity will increase by <Y> so that users will experience <Z>. Much clearer than simply saying "tech debt > refactor".