3 ms·

Technical debt becomes harder to refactor as more code depends on it. Then, there needs to be awareness and a sense of urgency. Technical debt accrues interest

Technical debt becomes harder to refactor as more code depends on it. Then, there needs to be awareness and a sense of urgency. Technical debt accrues interest. In my case, I use deprecation tags: - @deprecated on javadoc for Java (http://download.java.net/java/jdk9/docs/api/java/lang/Deprecated.html http://download.java.net/java/jdk9/docs/api/java/lang/Deprec...), JSDoc for JavaScript (http://usejsdoc.org/tags-deprecated.html http://usejsdoc.org/tags-deprecated.html), Yard for Ruby (http://www.rubydoc.info/gems/yard/file/docs/Tags.md#deprecated http://www.rubydoc.info/gems/yard/file/docs/Tags.md#deprecat...) - Obsolete attribute on .NET (https://msdn.microsoft.com/en-us/library/22kk2b44(v=vs.90).aspx https://msdn.microsoft.com/en-us/library/22kk2b44(v=vs.90).a...) - deprecated pragmas and macros in C++ - DeprecationWarning on Python (https://docs.python.org/3/library/warnings.html#warnings.warn https://docs.python.org/3/library/warnings.html#warnings.war...) By doing this: - You get a deprecation warning. - Some editors may highlight it. This signals people to stop using that code. This creates a sense of urgency to switch to or create a refactored alternative that is cleaner.

marcomonteiro 10y ago
+1 Though I do leave the occasional TODO or FIXME comment in code I prefer using deprecation attributes so that it results in a compiler warning. I spend a lot of time in Xcode so for me I like that autocomplete shows the method with a strikethru and the compiler warning is highlighted inline. It becomes glaringly obvious to everyone that we're adding to the technical debt by using the API.
doctorpangloss 10y ago
> Then, there needs to be awareness and a sense of urgency. Technical debt accrues interest. An alternative interpretation is that technical debt depreciates. That is, in a Darwinian way, clearly the product survived WITHOUT implementing the changes someone thought it needed. So is it really technical debt, or just baggage? Sometimes, debts are written down.
- webmaven 10y ago
  Sure, and sometimes you have to declare tech bankruptcy, and just do a rewrite from scratch (often accompanied by a switch in framework or programming language). Whether it is "baggage" or "debt" depends on whether it is accumulating interest (that is, it makes other changes such as adding features harder and harder to do).
- partycoder 10y ago
  Depends on the type of project. If your service is down, you can schedule some maintenance, fix whatever needs fixing and come back up after few hours. But if your service is large enough, a maintenance window costs you money, reputation, customer satisfaction and makes you breach contracts and service level agreements... you may want to find ways to minimize maintenance downtime. In that case you will want to make your code straightforward enough so mean time to detection and mean time to repair is low by emphasizing maintainability, namely, clean code with accompanying tests.
- stlHusker 10y ago
  "That is, in a Darwinian way, clearly the product survived WITHOUT implementing the changes someone thought it needed." ...and this is one reason that many business die, the assumption that past performance is indicative of future results. The reality is that you are making a bet with unlimited downside (e.g. a naked call in stock parlance) when you don't address technical debt. "Sometimes, debts are written down." One word: Enron.

marcomonteiro 10y ago

+1 Though I do leave the occasional TODO or FIXME comment in code I prefer using deprecation attributes so that it results in a compiler warning. I spend a lot of time in Xcode so for me I like that autocomplete shows the method with a strikethru and the compiler warning is highlighted inline. It becomes glaringly obvious to everyone that we're adding to the technical debt by using the API.

doctorpangloss 10y ago

> Then, there needs to be awareness and a sense of urgency. Technical debt accrues interest. An alternative interpretation is that technical debt depreciates. That is, in a Darwinian way, clearly the product survived WITHOUT implementing the changes someone thought it needed. So is it really technical debt, or just baggage? Sometimes, debts are written down.

webmaven 10y ago
Sure, and sometimes you have to declare tech bankruptcy, and just do a rewrite from scratch (often accompanied by a switch in framework or programming language). Whether it is "baggage" or "debt" depends on whether it is accumulating interest (that is, it makes other changes such as adding features harder and harder to do).
partycoder 10y ago
Depends on the type of project. If your service is down, you can schedule some maintenance, fix whatever needs fixing and come back up after few hours. But if your service is large enough, a maintenance window costs you money, reputation, customer satisfaction and makes you breach contracts and service level agreements... you may want to find ways to minimize maintenance downtime. In that case you will want to make your code straightforward enough so mean time to detection and mean time to repair is low by emphasizing maintainability, namely, clean code with accompanying tests.
stlHusker 10y ago
"That is, in a Darwinian way, clearly the product survived WITHOUT implementing the changes someone thought it needed." ...and this is one reason that many business die, the assumption that past performance is indicative of future results. The reality is that you are making a bet with unlimited downside (e.g. a naked call in stock parlance) when you don't address technical debt. "Sometimes, debts are written down." One word: Enron.