4 ms·

My opinion is that 'not thinking or understanding' the work shouldn't be labelled as technical debt. Technical debt should be a conscious decision about an impl

My opinion is that 'not thinking or understanding' the work shouldn't be labelled as technical debt. Technical debt should be a conscious decision about an implementation that needs to be revisited in the future, either for scalability, readability, extendibility etc concerns. Also, in that vein, not writing unit tests should not be considered technical debt, that is part of any implementation and should be factored into any completed work. The lack of understanding or thinking that might lead to people re-visit code should be viewed almost as a defect, along with not having test coverage. Therefore the term debt, I think, is a good analogy, because there is a conscious decision to accrue it. It should be reported regularly and monitored with the original decision behind it.

PaulHoule 5y ago
If it is ‘debt’ you actually plan to pay it. Sometimes I’ve put off writing the unit test (in an area of the code that has been around for months or years w/ little or no testing.) and made a bug fix or small feature. I had a plan to revisit it when coming back to the same zone and did. I’ll justify it like this. If a system is not well-modularized for testing and there isn’t a precedent for mocking or similar methods in that area, rushing to write tests can lead to test-induced design damage. If I walk away from the code a bit somehow it gets reprocessed in my mind and in the meantime I read up on my tools and understand other parts of the system often I come back and find the tests are quick to write and not damaging. That is, tests written hastily might not be a net positive.
- dgb23 5y ago
  I like the term "design damage" in regards to programming. Reminds me of my father telling me to take care of my things, when I was a child. It is much easier to clean up and order things if we do it continuously, because the implied "damage" is much weaker this way. If we think of programs as tools that need care, we might build things that have more longevity. It is also more fun to work with a clean and well ordered system of tools than with something that is messy and chaotic.
- foohoo_blue 5y ago
  "If it is ‘debt’ you actually plan to pay it." Exactly that, and it should be a decision to accrue it.

PaulHoule 5y ago

If it is ‘debt’ you actually plan to pay it. Sometimes I’ve put off writing the unit test (in an area of the code that has been around for months or years w/ little or no testing.) and made a bug fix or small feature. I had a plan to revisit it when coming back to the same zone and did. I’ll justify it like this. If a system is not well-modularized for testing and there isn’t a precedent for mocking or similar methods in that area, rushing to write tests can lead to test-induced design damage. If I walk away from the code a bit somehow it gets reprocessed in my mind and in the meantime I read up on my tools and understand other parts of the system often I come back and find the tests are quick to write and not damaging. That is, tests written hastily might not be a net positive.

dgb23 5y ago
I like the term "design damage" in regards to programming. Reminds me of my father telling me to take care of my things, when I was a child. It is much easier to clean up and order things if we do it continuously, because the implied "damage" is much weaker this way. If we think of programs as tools that need care, we might build things that have more longevity. It is also more fun to work with a clean and well ordered system of tools than with something that is messy and chaotic.
foohoo_blue 5y ago
"If it is ‘debt’ you actually plan to pay it." Exactly that, and it should be a decision to accrue it.