Eh, not so different: cooking anything in the kitchen generates dirty stuff. And the whole kitchen will also get dusty and dirty by itself, it will need some regular cleaning regardless of if we're using it or not.
The cleaning is part of the professional cooking. You don't usually leave your code dirty on purpose. In most cases, it's just that now you have more knowledge, more time and more incentive to improve it. It still fulfills its purpose. It's neither bad nor dirty - merely a chance to improve. Otherwise, we'd be talking about bugs, not tech debt. Granted, those would fit a kitchen analogy.
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly.
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
The concept of entropy does not apply here. The informational content inside the code does not change if untouched. Yes, languages may develop and provide more sophisticated semantics to solve issues, but that is merely the wording, not the working. But you cannot possibly solve TD that stems from these changes up front. Please stop it with the "borrowing" and "bad code" stuff. This is just a negative approach when you should be positive about the whole thing. Tech debt can even happen in clean code environments.
But it does not mean something bad had happend; quite the contrary: it means that things improved - the knowledge of the developers and/or their understanding of the issues that are solved by the code, the language they are using or even the use case that allows using an improved solution.
That's my sole point here. Stop it with the negativity around tech debt. We should probably even find a better term to make it sound more positive.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Eh, not so different: cooking anything in the kitchen generates dirty stuff. And the whole kitchen will also get dusty and dirty by itself, it will need some regular cleaning regardless of if we're using it or not.
The cleaning is part of the professional cooking. You don't usually leave your code dirty on purpose. In most cases, it's just that now you have more knowledge, more time and more incentive to improve it. It still fulfills its purpose. It's neither bad nor dirty - merely a chance to improve. Otherwise, we'd be talking about bugs, not tech debt. Granted, those would fit a kitchen analogy.
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly.
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
The concept of entropy does not apply here. The informational content inside the code does not change if untouched. Yes, languages may develop and provide more sophisticated semantics to solve issues, but that is merely the wording, not the working. But you cannot possibly solve TD that stems from these changes up front. Please stop it with the "borrowing" and "bad code" stuff. This is just a negative approach when you should be positive about the whole thing. Tech debt can even happen in clean code environments.
But it does not mean something bad had happend; quite the contrary: it means that things improved - the knowledge of the developers and/or their understanding of the issues that are solved by the code, the language they are using or even the use case that allows using an improved solution.
That's my sole point here. Stop it with the negativity around tech debt. We should probably even find a better term to make it sound more positive.