|
|
|
|
|
|
by Retric
1786 days ago
|
|
|
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. |
|
|
Another example of technical debt is when you write code without tests. You’ll probably finish much faster in the first week or two and then the manual testing will take more and more time. But how often did we see code bases without tests? All the time! And the managers don’t realize how much money they could save by focusing more on quality instead of features.
If you think you‘ll just implement this one thing and then never touch the code again, chances are high you‘ll just hack up the thing and copy paste some code everywhere until it kind of works. This is increasing technical debt, you take out a loan and someone in the future has to pay it back IF they want to make a change. But this is almost always the case, even if you don’t know it now.
My definition of technical debt I wrote down before reading the article: technical debt is the inability to make changes due to not making changes (on a conceptual layer) before.