Is technical debt an issue that only appears in an ongoing project or it is something that starts at the beginning?
Let's say I believe it's the latter. I'm going to try to convince you of how I arrived to that conclusion, or at least give you some ideas on how to avoid or deal with Technical Debt (TD).

Why is TD generated?

TD is something that can appear alongside the development of any project. Let's see some examples:

• If we assume that we are constantly improving our programming skills as well as our knowledge of business logic, concepts and ideas, then when we identify that parts of our code do not reflect all the new things we've learnt then we are in the presence of technical debt.

• When the delivery dates are close, we manage to do the things quicker than we thought. Sometimes we will be forced to do ugly code to ship things faster.
  Also, in the same idea, bad estimations and TD are really good friends. Do you remember when you said in that planning session "It's ok, I'll take it, it will take me two hours" ? Then, after several days of hard work, you finally finding out why the things didn't work, but as you are at end of sprint, you have to solve it now. Well, probably you will fix it adding some technical debt to compensate your delay.

• Teams change all the time. The guy who has all the tricks about that weird framework leaves us with the problem, we wish him good luck! But next Monday, it's a rule that an issue related will appear. The best scenario occurs if the guy is still working at the company, but he can only give us only a few hints, because he's probably dealing with a new hell. We will try to do our best, we will fix the things, but as we still don't have enough knowledge about the new things, we will probably get the things done, but maybe that way is not the best way to solve that problem. Along the time we might include new features... but we know that the curve to get the things done has its cost. So, we created along the way some TD.

Ok! I'm getting nervous...

TD is not a monster, in most cases you shouldn't be scared. It's something that every project suffers to a degree.

The things you should worry about are:

A.- Finding the methodologies and "treatments" to have TD under control.
B.- Attempting to guide and convince the product owners that spending time and money on improving the code will lead to a better product, both for our users (who use our creations) and coworkers (who have to create new things on top of this code). The product might need new features, but taking the time to fix it will make the guys working on it happier and allow them to work faster.

Maybe it's an issue to discuss in another post, but negotiating time for improving code it's not an easy thing. Almost every developer knows that you need time to refactor and to improve the code, but some managers don't. Just to make it simpler, I will focus the last part of this post in point "A".

Do we know how much debt we owe?

The amount of TD is difficult to show, accept and deal with. There is no specific metric or smell that can be used to evaluate the amount of TD present. Although we cannot measure it objectively, it is a fact that we can detect it ourselves. Honesty becomes a really valuable asset for this.

We may think as we are doctors and our project is our patient. And when we ask him, "Hi, tell me what's happening" he will show and tell us the symptoms. If we care, we detect the first "pain point", and we can cure that, but in some way if we are late, maybe we can face the ugly truth that maybe we can't save him. Of course we are so lucky, we can just think to make it from scratch (I'm not saying it's free, right?).

Sometimes we are not quite as good doctors as we should. Sometimes we are lazy, or we are just starting new practices over our patient, sometimes we believe that we are doing the best and clever practices we can do for our patient... but that ego could also be our worst enemy. We do not approve a doctor that makes mistakes just because of his ego, but same issue affect us sometimes, and we forget that our patient is in pain. If we are aware that we are always learning, and we can do always better, we can do more defensive and reliable code.

Sometimes we have to face a variety of solutions, but we have to accept that maybe sometimes the best decision is start from the ground is better than trying to fix that kind of project.

Have you ever seen any metric that can help us to decide which is the best decision, refactoring vs starting over? Almost every developer thinks that second choice is the best one, but do we have any metric to assert that? do we have any trend about justifying how many hours we spent a week giving support to the sick and weak project?

Maybe starting over again isn't the difficult decision, and the really hard one is to convince our leaders/partners/clients that we are taking the right way. Again, we arrived finally to point B. There are several options and consequences to be aware before trying to convince managers/Product owners that we need to re-build it.

Prevention is better than cure. Be aware.

First of all you have to focus on understanding which is our patient's status.
And then we have to pay attention to the relevant metrics that allow us to monitor his behaviour.

Our backlog should reflect that we are aware of the things that make up TD. Just having visibility about our issues, will help us tackle them in our free time or maybe as part of another related story. Eventually we will want to take this ugly thing out of our TODO list.

Some concrete signals you should be aware:

• When you find that for a new feature, you might have to make changes in a lot of places, sometimes you'll find yourself saying "Really? here?!"
• If your backlog doesn't have at least one single point about refactor or changing the way you're doing things in your project.
• If your team is not practising Code Review or code review doesn't pay attention about design or good code practices.

Leave the world better than you found it

Not only a "mega-refactor" is the medicine for improving and solving TD. You will see that you can (and you should) feel more secure about how the things are going on after making tests (if they already exists, you should consider yourself lucky... if not, you have a new enhancement opportunity), add some improvements, make variable names more clear and so on. You can make the difference, even if they are baby steps. If the whole team accepts this kind of responsibility, you might find that the whole project will start looking different in a short period of time.

Additionally, this attitude will help stop the "broken window" syndrome. When this starts it feels harder to clean up the disaster.

Conclusion

Technical debt starts at the same time a project is starting. You should be aware of that. The things you know at the beginning will be different in the future, but your code will not change unless you change it. If you don't, TD will eventually become noticeable.

So, if we know it exists, we have to understand that it should be in our backlog like any other issue. Sooner or later we have to deal with it.

Maybe it's possible that product owners will not see its immediate value for the project. But in the future when issues are faster to fix and new features easier to implement, it will be because we refactored and the TD got paid. This will also affect how the team feels about the project.