Hacker News Reader

Comment by badminton1 | Hacker News Reader

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/Deprec...), JSDoc for JavaScript (http://usejsdoc.org/tags-deprecated.html), Yard for Ruby (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).a...)

- deprecated pragmas and macros in C++

- DeprecationWarning on Python (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.

View on HN

> 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.

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).

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.

"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.

+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.

Reply on news.ycombinator.com