Introduction

Technical debt, what is it? To understand it, we need to understand the clean code and the art of writing it. This article is more of theoretical thoughts about the topic, and if you are interested in some practical examples of the clean code (for JavaScript) you can check it out here:

Below is a quote from the article above that is useful for us here.

If you care about the code itself and how it is written, instead only worrying does it work or not, you can say that you practice and care about the clean code. A professional developer will write the code for the future self and for the "other guy" not just for the machine. Any code you write is never written just once rather it will sit down and wait for the future guy and make him miserable. Hopefully, that future guy won't be you.

Based on that, the clean code can be defined as the code written in such a manner that is self-explanatory, easy to understand by humans, and easy to change or extend.

Technical Debt

We can describe this debt just like any other debt. For example, you can get a loan from a bank to boost your economic status. The newly acquired income will grant you the ability to purchase items instantly and faster than usual because before taking a loan you didn't have enough resources to purchase what you need. The downside is that you must, besides paying for the principal, pay the interest for the taken loan, which will, in the long run, slow you down with your purchases.

Your ability and speed of purchasing new items will start decreasing at the point when you spend the loan you've taken from the bank. At that point, you will be in debt which will be paid off your base earnings (the amount you had before the loan) which means that you won't be able to purchase any new (expensive) things until you pay your debt to the fullest.

If we take this analogy and try to port it to our style of developing applications and writing code, we can say that the same thing could happen if we are not careful. To be more precise, our decisions at the start could bring up the speed of development, but in the long run, it might slow us down significantly.

An example of these decisions would be to chose to develop our application without writing tests. In the beginning, we will develop new features faster, but later on, when the application is big enough, it will slow us down and we will be required to pay out the debt by writing the tests.

Another bad decision would be not caring about the reusability of the code you write. For example, if the same, or similar code already exists in your codebase, the worst thing you can do is copy the code and alter it to meet your new requirement. This is exponential growth in the wrong direction. Again, at first, you will develop features faster but later on, when your application gets big enough, maintaining it is going to be a hell, and you will be required to pay off the debt by introducing abstraction and refactoring all the code you've copied to be reusable.

The Most Common Reasons for The Technical Debt (in my opinion)

  • The Deadline

Yes, we all have encountered a tight deadline when the client needs something ASAP, and it doesn't care about how you do it as long as it is done on time. This is the worst case to deal with, especially if you like clean code and doing things properly. In a tight deadline, you are forced to deliver, and knowing that you need more time to do it properly makes it even worse. You deliver the feature, but the code is crappy, and you know it.

The debt, in this case, is obvious, and you will spend some time trying to convince your client to redo the things already done. The main issue is that they don't get any business value and will be hard on allocating time for you to refactor something thus giving you the opportunity to pay off your technical debt.

  • The Project Architecture

If you are not involved in the architecture, and you are not allowed to change something in that scope, you are destined to follow the existing workflow. It might be possible that you have a better idea that will work better, but if you are outside of the decision process, you will have to do it as required.

Paying off your debt will have to wait until you prove yourself worthy to change something in the project architecture.

  • Not Caring About the Clean Code

Sometimes people just don't care. They don't enjoy programming and not in love with software development. They just work it off. These kinds of people will often look the easiest and the shortest way of doing things without caring about the codebase.

If you are not like that, the debt will be on you and you will not forgive yourself if you don't pay out the debt for them as soon as you get the chance.

  • Lack of Functional Understanding/Explanations

Quite often, the user stories are either half-done or not understood 100 percent by the developers. In this case, you will work by the way you understand it and how much of the requirements are defined.

Needless to say, that as soon as the user story is updated or after a couple of meetings with the product owner, you will be required to pay your technical debt and rework your implementation in the way to fit the full specification.

  • The Lack of Communication

If there is a lack of communication in the team or across the company, it might end up with a situation where many developers work with an outdated understanding of the domain and with limited knowledge about the same.

If this is not improved over time, the technical debt could be quite big in terms of finishing required functionalities or doing serious rework.

  • The Lack of Expertise

This one is a short one. Sometimes people do not possess enough knowledge to write clean code. They simply do the best they can, but it's not enough and it will leave the entire team with technical debt that will reappear as long as the unexperienced person in the team, or until the person is trained properly by a mentor.

Conclusion

I will end this article with a single sentence.

Try to predict what might cause technical debt and do your coding in a way that avoids it, but on the other hand, if that's not possible, as soon as you identify the debt, pay it off as soon as you can, and it will make your life easier.

If you liked what you've read, please consider supporting me by buying me a coffee. To stay tuned, follow me on twitter or subscribe here on devinduct.

Of course, feel free to leave a comment and express your opinion about this.

Thank you for reading and see you in the next article!