I don't use the term technical debt and neither should you(charemza.name)
charemza.name
I don't use the term technical debt and neither should you
https://charemza.name/blog/posts/software/communication/I-dont-use-the-term-technical-debt-and-neither-should-you/
2 comments
> why not remind people of the purpose?
To answer this, I suspect that trying to change what certain words/phrases mean to people en-masse is extremely difficult, to the point of impossibility in most cases. However, we each have the power to be clearer in the words we use so they are understood by the people we're communicating with.
> engineering quality matters
But also, this to me suggests that there is some sort of absolute definition of quality, but it's much more nuanced. Nothing is inherently "bad quality", but instead has certain consequences, which may or may not happen or may or may not be acceptable in certain circumstances, and you might not even know what these are until the future. This I think is the point I'm trying to make - there is no absolute definition of engineering quality, and I suspect the term "technical debt" all too often suggests there is.
To answer this, I suspect that trying to change what certain words/phrases mean to people en-masse is extremely difficult, to the point of impossibility in most cases. However, we each have the power to be clearer in the words we use so they are understood by the people we're communicating with.
> engineering quality matters
But also, this to me suggests that there is some sort of absolute definition of quality, but it's much more nuanced. Nothing is inherently "bad quality", but instead has certain consequences, which may or may not happen or may or may not be acceptable in certain circumstances, and you might not even know what these are until the future. This I think is the point I'm trying to make - there is no absolute definition of engineering quality, and I suspect the term "technical debt" all too often suggests there is.
"Technical debt" was never a technical term. It is an analogy to help non-technical people understand why engineering quality matters. People understand financial debt and why it costs more in the long run to carry a lot of it. "Technical debt" is supposed to be a quick way to explain why not to carry under-engineered solutions for a long time. It is supposed to express the utility of choosing to take it on as a strategic decision to move towards a goal faster, combined with the longer term pain of paying it off.
As an analogy, it remains a highly effective term.