How to Avoid Technical Debt With JIRA and the Iron Triangle

Known as the Iron Triangle, this model describes the conflicting trade-offs you’ll face when managing a development project.

The Iron Triangle makes good sense: a product with more features will take longer to create, which means it will cost more.  Likewise, if you want something sooner, you’ll find yourself choosing between decreasing the scope or increasing resources, which again, will cost more.

A common project management practice is to ask the customer which two of the three they want, because you can’t achieve all three. We know that if a customer wants a high quality product with lots of features, for example, then they will have to wait a while for it.

But we’re running late!

We’ve all been in this situation at one time or another: your release is running behind schedule. According to the Iron Triangle, you have three choices.

• Reduce scope
• Increase resources (and therefore cost)
• Move the deadline

Okay, we’re among friends, so let’s be honest with ourselves. There is a fourth option, a hidden “fourth side” of the triangle. What about sacrificing quality in order to keep the project on track?  How many of you would consider one of these a “temporary fix”, “a quick fix”, or even a “dirty slimy hack” in order to achieve a target release date?

In fact the Iron Triangle is often pictured with the word quality in the middle of it. This represents the fact that when the triangle gets out of shape, it’s quality that will be affected first.

This is exactly what we don’t want.

The impact of technical debt

1. Bugs

Firstly, there’s the obvious potential for bugs. Not only do these reflect badly your business reputation, but they also represent a huge efficiency loss. The development team gets redirected to bug fixing and releasing patches, rather than adding value to the product. Instead of moving forward, development gets stuck.

In addition, bugs bring the additional costs of your account managers apologising to customers, while your service desk staff are busy raising issues and investigating the nature of the bugs.

2. Sacrificing speed

Secondly, there is also the fact that future speed of new development will be impacted by these so-called ‘shortcuts’. Your codebase will be scattered with areas of the code that will need to be rewritten at some point in the future, and there’s going to be a cost in doing that.

Any bug fixing work is also going to take a lot longer than it needs to, especially if the code isn’t covered by unit tests, comments that make sense, or code that hasn’t been refactored.

3. Lack of documentation

Thirdly, it will inevitably lead to a lack of documentation and lack of proper architectural consideration. This may seem like a small detail – it can all be coped with while the developer who wrote the code still works for you.

If they leave, however, unpicking everything can be extremely painful. Quite often large areas of code need rewriting, which will always have unexpected impacts on your schedule.

All of the above issues fall under the umbrella of ‘technical debt’, and this ‘debt’ can build up gradually in secret, increasingly slowing development down.

Avoiding technical debt using JIRA Software

To avoid technical debt creeping up on you, you can introduce practices to make the debt transparent and to make sure you spend some of your resources dealing with it.