Editorials

Code Smell vs. Technical Debt

The last couple of editorials I have been considering the topics of Technical Debt and Code Smells. Two brave people have contributed their thoughts on these practices.

Dilip writes:

This Topic is of prime importance not just because of the situations mentioned by you

such as :

Fixing errors, Readability, trying to follow standards etc. but also because


  1. Every technology deprecates certain codes/classes/features to be replaced by newer and many times better ones.
  2. The support for legacy fast approaches an end, e.g. handling of IPV4.
  3. A totally new approach is now available in the technology which calls for stale code to be completely rewritten e.g. Web Sockets in place of HTTP. Everybody expects web to behave like a windows application with many events and fully interactive.

The question is when to do it and how to tackle this gigantic task which many times

many not pay you a cent.

The answer is Survival. If you want to survive in the business you have no choice but to do it.

Most of the times in a phased manner.

Marc writes:

When referring to known issues with code that are left standing to be addressed at a later date, the metaphor of technical "debt" is far more apt than that of "smell". The two go hand in hand of course, and this column would really have benefitted from openly acknowledging and interacting with yesterday’s. A "smell" is a symptom, an ugly one that hopefully leads to its source so that the problem can be solved, or at least the smell "contained" with appropriate documentation (e.g. "//HACK:…" comments) and cataloged as "debt".

Editor:

What’s the difference between a code small and technical debt? In my opinion, code smells are hopefully something that can be solved in a fairly short period of time. A good example would be duplication of code. You may have two different Objects having a method that is identical. That method might be pulled out and located so that it can be shared in both objects resulting in consistency, extensibility, etc.

Often these are things that can be resolved in a few hours or less, and may be addressed when tasks are completed more quickly than estimated.

I tend to think of Technical Debt as the collection of Code Smells along with bad architectural choices. Technical debt tends to take a longer time to resolve.

One thing we can all agree on is that at some time you are going to pay the price for Code Smells or Technical debt. The more you have, the higher the interest you are going to pay.

My thoughts have not been researched, and are probably just arguementative. Perhaps one of our readers really into these terms may clarify more fully? Get into the conversation online, or drop an Email to btaylor@sswug.org.

Cheers,

Ben