Technical Debt

In our real world of software development we make some compromises, we take some shortcuts to meet the deadline and to deliver a viable product. There is a value in doing something within that timeline. Let's not say that to we are encouraging poor design or bad quality of code but let's say that there is value in doing something right now. Agreed?

A little debt speeds development as long as it is paid back promptly. Real problem is when it is not paid back promptly and on time.

Now very important question - Is technical debt bad?

Answer really depends and we need to understand what's the trade off? But remember if this debt is not paid off promptly then definitely it's going to be bad. Really bad :)

Let's look at these 4 quadrants to group technical debts.

Deliberate-Reckless: It means developer knows that it is bad but still doesn't take correct path. "We don't have time for design" which shows unhealthy working environment, team is not adaptive and heading towards disaster. There are no trade offs here but still technical debt is accruing.

Accidental-Reckless: Let's take as an example and say we have 2 new team members just graduated out of college and working on a project eagerly but code is becoming quite messy day by day, it is not that they are doing it intentionally but they did not know any better and they did according to their knowledge. Such type of debts are categorized in this quadrant.

Deliberate-Prudent: This is the most acceptable type of debt. In this, all the choices and options are taken in to consideration and team knows exactly what they are doing and why and there is justified trade off and hence allowing debt.

Accidental-Prudent: This is like at the time of planning and design they did look for options and agreed upon one available option but later down the line it turns out that there is other better way of doing it. It is that "Oh yeah.. that's right !!" moment.