DEV Community

Discussion on: What types of features typically lead to lots of tech debt?

Collapse
davepacifico profile image
davepacifico • Edited on

I don't think you have to consciously decide to take on debt in code. First of all, you could just not realize you're making a bad decision. Maybe you are inexperienced. Second, and I think more importantly, you can do everything right based on the information you have at that moment and then it becomes debt later as you get more information, understand more about new use-cases, etc. This is an oldie but a goodie by Martin Fowler - martinfowler.com/bliki/TechnicalDe...

Collapse
citizen428 profile image
Michael Kohl • Edited on

For better or worse everyone uses different definitions for these terms, I just shared mine ¯\(ツ)

With that said, let me reply to the two specific points you mentioned:

  • Unless you're the sole developer, the first one seems like a process problem, some senior developer should have caught that during review.
  • IMHO changing requirements are a given in software development, so I don't see any "debt" in that.

So to sum up my definition: if you did the best according to both your ability and available information at the time, I would not consider it technical debt, just code that needs changing. For me technical debt are the pieces of code you already know could be written better, but for whatever reason that just isn't an option right now. Like all debt it accrues interest, and the longer you wait to pay it back the more it's gonna cost you.