4 ms·
> Without the code the company is nothing, so it's definitely not 'debt'. I reconcile the concept that code is a debt with your statement in the following way:
by jdgiese 7y ago
> Without the code the company is nothing, so it's definitely not 'debt'.
I reconcile the concept that code is a debt with your statement in the following way:
The feature produced by a piece of code can be an asset, but the code itself is a debt.
Thus, for a new feature to be valuable, you want the value added of the feature (or asset) to out-weight the cost of the code (or debt).
As a general rule, the complexity that comes along with a piece of code grows as the code-base and feature set grows, thus, for a young codebase, the value of a feature more easily out-weights the cost of the code.
- sonnyblarney 7y agoAnything in any other business terms that needed to be used, created or maintained to create value for customers would not be debt. 'Technical debt' is just not debt, it's just an interesting way to think about it, and a neat use of lingo. There are any number of other business practices for which one could try to apply the same analogy, but it wouldn't work because very quickly the term wouldn't seem right. For example 'training employees' for a situation, knowing they might need to be trained differently in the future, is not going to be regarded as debt. Same thing for processes, investment in equipment, parts, materials etc..