You often hear stories from unhappy programmers who work on code that’s hard to maintain because it was written in a hurry.

On the other side, managers are stuck chasing deadlines and clients need everything done as soon as possible so they can reach a particular business objective.

How do you reconcile these two sides and produce software of sufficient quality but in a reasonable time?

Nowadays, if you need $100,000 to buy an apartment and you don’t have $100,000, you go to the bank and get a loan which you will be returning for the next 20 years.

After those 20 years, with an effective interest rate of, let’s say, 6.10 percent, you will pay off about $170,000 — because of the interest rate, of course.

You’re OK with that, as you effectively pay the price of buying the apartment now and not in 20 years when you might have saved enough money to buy it in cash.

So to have something today, you are willing to pay more in the long run.

When you work on a software project, you can do certain things well, or you can do them fast.

Every time you sacrifice quality for speed, you incur something in your project called technical debt.

When I say quality, I don’t necessarily mean the quality of what the user perceives, I’m referring to the architecture of the solution. I’m not talking about the facade of the house; I’m talking about the foundations on which it was built on.

The main influence of technical debt on a software project is that it makes the project harder to maintain. Introducing new functions takes longer and you are generally slower at everything.

Every time someone says “Just slap it together so it works” and doesn’t choose the best architectural solution, they incur technical debt on the project.

Getting into technical debt is not necessarily a problem on its own; the problem is if this technical debt is never “paid off”.

Technical debt is paid off by code refactoring. Refactoring is the process of changing an existing program code internally or rewriting it without changing its functionality or external behavior (the behavior which is seen by end users).

You do this so you can maintain that code and introduce changes more easily, and more quickly in the future (that is, to pay a smaller “interest fee”). Refactoring is like cleaning your closet. On the outside, everything is the same— the same clothes are inside the closet. However, if you fold and organize the clothes better, the next time it‘ll be easier to find a certain item.

You won’t need half an hour to get dressed, and you won’t turn the whole closet upside down while doing it.

Often organizations avoid refactoring because they don’t recognize the value of it. And they often don’t recognize the value because refactoring doesn’t provide any visible and obvious benefits.

The application does the same thing before and after a refactor, so why waste time (= money) on refactoring at all?

But you should invest in refactoring. If you don’t periodically pay off that debt, it will just accumulate, the project development will get slower and slower and, in the end, you will go bankrupt.

Every project contains a certain amount of technical debt. This is normal and does not represent a problem.
Having to pay $1,000 / month is not a problem if you earn $7,000 a month. But, if you have a $4,000 loan and earn $5,500 per month, that’s a problem.

It’s like in the real world — if you accumulate technical debt long enough, you will face technical bankruptcy. Technical bankruptcy means that you will probably have to rewrite the whole application from the beginning because the code is simply so bad that you can’t even work on it, let alone to refactor it.

You wouldn’t be the first or the last in the world to do that. Joel Spolsky wrote an article a long time ago about Netscape rewriting all of their applications. The reason was a large amount of accumulated technical debt and as a result, in the end, they had to close down.

I would define a technical manager as a person who takes care of both the business and technical aspects of a project.

They are people who understand how something should be implemented technically, but they also understand the underlying business dynamics of the project.

This person has to decide when the project should raise technical debt and when it shouldn’t.

In the end, here are several things that should be kept in mind when making these decisions:

I believe that technical debt is something that should be controlled and planned. You shouldn’t be careless about it because in the long run it may turn into a disaster.

The business side of the project will be unhappy because features are not created fast enough and it takes a lot of time for programmers to implement some minor things.

On the other hand, programmers will be unhappy because they constantly have to struggle with bad architecture instead of doing creative work.