Introduction

As someone who crunches out code, whether moderately or a lot if you’re like me. You must have incurred some technical debt somewhere along the lines.

Development approaches

Technical debt is the term given to a certain programming scenario. Assume you had a project with a target deadline. As the technical lead of the project, you are sometimes faced with two decisions which are:

The long and proper way

Using this approach is the most ideal way of development. Many best practises of development are followed using this way.

However, the downside is that it may take longer to complete the task at hand. There is a higher risk of going over the maximum given time to complete the project.

The upside is that, when there is a requirement to change the code at a later code, it would probably be easier to do that since all the pieces are very decoupled.

The quick and dirty way

Using this method, you would probably finish the project on time. Following this way, you may not follow best practises and patterns, and maybe not even test your code. Enough consideration may not be taken to make sure the code modules are decoupled enough.

However, in this method, a project would most likely be finished on time given that there are no other external problems. The downside to this though may be that, when there is a need for code change in the future, it may come at a cost, hence the term technical debt.

The reason its called technical debt is that, ease of change and best practices were sacrificed for speed. Even though we knew that this would come at a cost later in the future, but because of the time( or maybe other factors) constraint, we had to do it the quick and dirty way.