Technical Debt: The Most Forgotten (and Hated) Feature

Is technical debt an issue that comes with the project on going, or it’s just something that starts at the beginning of it?

Well, Let’s start with the conclusion.

Let me said that I’m in the second position. I’m going to try to convince you on how I arrive to that conclusion. At least I will try to show you the reason, giving you some ideas to avoid or deal with Technical Debt (T.D).

Why is T.D generated?

Adding T.D into any project is something that happens at the same time we are developing it. Lets see some examples about that:

  • If we assume that we are constantly improving our programming skills along with ideas, concepts and business logic. When we identify old/obsolete business knowledge in our code, when some old features become into bugs, every time we don’t reflect all the new things we learnt about the business in our code, we are in 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.

  • Bad estimations and T.D are really good friends. When we realize that we really did it wrong, do you remember when you said that Wednesday “It’s ok, I’ll take it, it will take me two hours”? and you were on 2pm Friday finally finding out why the things didn’t work, but 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 enought 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, we already know, that the curve to get the things done has its cost. So, we created along the way some T.D.

Ok! I’m getting nervous…

T.D is not a monster, in most of the cases you shouldn’t be scared, it’s an issue that just occurs to every project. Every project will suffer it more or less. The things that you should worry about are: A.– Find the methodologies and “treatments” to have T.D. under control. B.– If the project worth it, try to guide and convince the product owner that the time and money invested to improve the code will give the users (which suffer our creations) and our coworkers (who implement things on top of our code) some benefits that will make the product great, because the product maybe needs new features, but also needs to be fixed or evolve in short time, we need to work properly, making happy the guys who work on it.

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 about needing 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 we debt?

The amount of T.D is difficult to show, accept and deal with. There is no metric or smell to be used for evaluate its amount. As we cannot measure it, but is a fact that we can detect it, Honesty suddenly became a really valuable asset for us. “” We may think as we are doctors, and our project 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 “rush”, 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 again (I’m not saying it’s free, right?) but well, the metaphor is not so far cruel than a real doctor case.

Sometimes we are not quite 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 which makes mistakes just because 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. And sometimes if you have enough experience, you will arrive to the decision that maybe start from scratch 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, refactor vs start 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 guy?

Maybe start over again isn’t the difficult decision, and the really one is to convince our leaders that we are taking the right way. Again, we arrived finally to point B. Exists several things to do and be aware before trying to convince managers/Product owners that we need to re-build the project.

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 understand about his metrics and behaviours.

Our backlog should reflect that we are aware about the problems and T.D. Just because if we have visibility about our issues, we could face them in the free time or maybe adding some points to another related story, because at the same time we can try to let this ugly thing out of our TODO list.

Some tips 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. * If you find that to make a test for a new functionality it’s quite difficult just because there are a lot of dependencies.

Let the world better than you found it

Not only a “mega-refactor” is the medicine for improving, and solving T.D. 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.

In the other hand, this attitude will help to stop “broken window syndrome”. When this thing started, it’s really hard 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, T.D will notice you in some way.

So, If we know it exists, we have to understand that it should exists into the backlog like any other issue. Later or sooner we have to deal with it, if the project worth it.

Maybe it’s possible that the product owner will not see it as an income from project. But in the future, when new things comes in and your team solve them really faster/slowly than they would think, T.D and refactor will be the reason, for sure. The decision we take will drive us through the happy or the sad path, it’s all in our hands..

T.D. is about responsibility, about how much we care about the things we do, is almost the same that care about the people we share our time and effort, the results will always affect them.

Comments