//TODO: Tackling Technical Debt

This isn't the first article you’ve read about Technical Debt, nor will it be the last. Technical Debt is here, whether you like it or not, and that’s OK, but if you don’t pay it off it will just keep ballooning bigger and bigger until you are under water.
The reason it's called debt is not just a catchy play on words, but because for a software product, it acts exactly like financial debt; at the beginning, it's manageable and taking on small amounts of it is not only an attractive thing to do, it can be the right thing to do to get where you need to go. Now, if you pay it back quickly, the debt hasn't accrued much interest and is relatively easy to pay off, but the longer you let it sit, the more interest it will accrue and the more expensive and difficult it will be to pay off.
 
Let's take this metaphor further and consider a couple of examples:

High interest rate Technical Debt:

Let's say that we have a data-access component that acts as the template for the rest of our system and is reused consistently from one component to another. A new business requirement comes about and requires either a refactor of the current interface to accommodate this, or a simple addition to the interface to satisfy the requirement immediately. After evaluating the market opportunity and cost implications, the decision is made to go with the immediate solution and accept the technical debt to pay off at a later date.
Now, the decision to do this quickly was to satisfy a business requirement, which is what all software developers should be striving to do at the end of the day, but this debt comes with a high interest rate; the longer it is left unpaid, the more difficult and costly it is to actually resolve. In a few iterations, the developer will have to go and touch all the existing code from before (the principal) in addition to all the other additions that have been added since (the interest). Since this is a key component that is deep in the system, each change is risky and can introduce bugs (late payment penalties and fees)

Low interest rate Technical Debt:

On the other hand, let's consider a newly released (or even unreleased), not widely used feature in the system has a new requirement. The business would like to get the new feature out as soon as possible to capitalize on the upcoming trade show season. The developer will need to make the same decision as before and decides to implement the quick and dirty solution and accept the debt.
In this case, this debt can be considered a very low or even a no-interest loan; there is much less consequence to introducing a bug in this system as there are not many users as of yet. Realistically speaking, this system may not survive past the demo stages and be overhauled once it matures to a full-fledged product.
The fact of the matter is, debt isn't always bad, but when it's too much or hangs around too long, it can almost cripple the application and even kill a product. The key is to be able to identify and quantify the amount and type of debt that has been accrued.
The same discipline that applies to financial debt should be applied to technical debt. Some of those are:

Track and analyze spending:

Lets face it, if you don't check your statements occasionally, your debt will spiral out of control. The same applies to technical debt. There are countless ways to track down what has been decided to be taken on as debt; bugs or tickets, code analysis on comments or even a spreadsheet are all fine ways to do this. Ultimately, it all needs to be tracked and its “interest” calculated.

Develop a spending plan:

Just like your finances, your net income and expenditures are known in advance and you have to make a decision where you are going to spend your resources. Always consider your debt to be part of your running cost and budget accordingly.

 

Pay off outstanding debts:

Once your debts start piling up and accruing interest, it's time to start chipping away at the mountain of debt. Consider your debt expenditure and utilize your analysis to determine which ones to pay off first.

Don’t create any new or unnecessary debt:

Both time and money are finite resource and hard to come by, so they should be spent wisely. Always consider all options and try to consider all options before taking on new debt. Debt should be considered a last resort and a costly one at that. Once all those the options are considered,
At the end of the day, writing software will always end up creating some kind of debt, but, just like in life, you need to know when to take the debt and how much of it. //TODO: add clever closing statements


Comments

Post a Comment

Popular posts from this blog

How to unit Test Entity Framework

So, now we have the picked the best ORM for our purposes, chances are, you want to test it. We all test our code all of the time with close to 100% coverage, right? Yea, that's what I thought. Throughout the years, I've found that most developers don't test their code thoroughly because a handful of reasons: The tests written are too brittle and break with every new feature. It's too tedious to try to and mock out every little thing Its just too difficult; things are abstracted out way too much nowadays and I cant get them to pass  You know, they're not entirely wrong; I've seen code written to perform CRUD on a table that could only be described as 'awful'. Firstly, the amount of code to do that simple operation was just absurd. Secondly, the repository pattern needs to go; it just doesn't make any sense to me to try to anticipate every possible request that's needed and create a member for it (read over-complicating things). Thi...
Read more

The Yin and Yang of software

Image
As I was looking out of the window of my flight, I looked on to see the house and neighborhoods below and couldn't help but admire the beauty of the organization intertwined within the chaos and randomness of the surrounding environment. I couldn't help but draw parallels to my own world, as a software architect for almost the last decade, as to how similar that world is to mine. I have always struggled trying to clearly explain the difference in rules between a software architect and a software developer. Even more difficult has been trying to explain the difference between the different types of architects themselves. Barcelona Spain. Bing Maps A lot of people tend to think that an architect is something one becomes after they are the top level developer they can be, the next step up so to speak. That might be because the salary structure in our industry rarely values nor can properly price developers to begin with. That's a whole other blog post in i...
Read more