Have you ever procrastinated on a chore that later cost you more time and stress? Have you ever fumbled in a course or subject thinking that it would end there only for it to haunt you like a ghost with a vendetta? 😰. In the world we live in today, we have several idioms, proverbs and quotes that more or less tell us to look beyond the present and invest in the future, we have terms like "delayed gratification", and proverbs like "a stitch in time saves nine" to help drive home the point that we shouldn't always take the easy way out.

A RELATABLE EXPLANATION

In the field of software engineering, we have a similar term with far-reaching consequences, we call it "technical debt". As junior developers, technical debt is somewhat unavoidable when working alone, in organizations with a development team or an outsourced development team, technical debt has very scary implications. So what is technical debt? well, technical debt is more or less the consequence of poor software development practices or inadequate architecture when developing software solutions. Recall that we reviewed architecture (using monolithic and microservices as examples), using wrong architecture is like building a foundation for a bungalow and later deciding to upgrade the house to a ten storey building.

TECHNICAL DEBT EXPLAINED

Technical debt (or tech/code debt) basically refers to the price that will be paid for either poor development practices, inadequate architecture or rushed product development. Like cheating the system, eventually, the chicken comes home to roost. Software solutions that are poorly developed live on borrowed time, there will come a time when such products have to be refactored (fixed) or abandoned in favour of developing another from scratch. Some projects take too much time to fix as such it is decided that it's better to build a new one than to fix an old one.

IT IS SOMETIMES BETTER TO LET GO

For non-developers, it might look like throwing a baby away with the bathwater, however, it's the more economical decision when you consider the fact that the time of developers is quite expensive whether you're paying them per month or per hour. It is easier to set a deadline for building a product than fixing a product. I remember looking through some of the things I built when I began my developer journey; they are horrible 😥. I wanted to fix them, by the time I was done looking through my messy code I knew it would take me too long to refine it and I simply prioritized learning new things over spending time obsessing over my past.

FINALLY...

My personal decision is similar to how developers and some organizations see things. As newbie developers, it's highly likely one will rack up technical debt and simply because newbie developers don't know better. There are however times when experienced developers willfully incur technical debt because there are times when "done" is better than "perfect". Depending on business needs and priorities, teams may have to knowingly rush products in a bid to gain first mover's advantage or marketshare. In business, speed sometimes trumps other factors of production.