DEV Community

Discussion on: The Technical Debt explained with a kitchen analogy.

aarone4 profile image
Aaron Reese

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

Thread Thread
aarone4 profile image
Aaron Reese

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

Thread Thread
aarone4 profile image
Aaron Reese

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

Thread Thread
aarone4 profile image
Aaron Reese

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

Thread Thread
aarone4 profile image
Aaron Reese

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

Thread Thread
aarone4 profile image
Aaron Reese

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

Thread Thread
lexlohr profile image
Alex Lohr

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.