I think in general writing code based on hypothetical requirements that never materialize is just wasteful. And leads to bad code.
You can ship good code fast.
Shipping slow is not a guarantee of good code.
I think the pathology here is defending "sloppy" or "negligent" code by the need to ship fast, when in fact you probably could ship as fast with cleaner code, but the coder just could not care enough.
This isn’t about knowing what changes will be made just that change is inevitable. Technical debt arises because it’s faster to write brittle code.
The problem with brittle code is it makes any change more difficult. The most obvious example is variable names without semantic meaning. The compiler doesn’t care if you’re using “asdf” but such choices collects its pound of flesh every time anyone messes with that section.
fsloth|4 years ago
You can ship good code fast.
Shipping slow is not a guarantee of good code.
I think the pathology here is defending "sloppy" or "negligent" code by the need to ship fast, when in fact you probably could ship as fast with cleaner code, but the coder just could not care enough.
Retric|4 years ago
The problem with brittle code is it makes any change more difficult. The most obvious example is variable names without semantic meaning. The compiler doesn’t care if you’re using “asdf” but such choices collects its pound of flesh every time anyone messes with that section.