Skip to content
Technical Debt

How is technical debt related to progress?

How is technical debt related to progress? I would suggest that they require us to consider progress in software projects in two different dimensions.

Work on a software project is often linear. Point A to point B. From bug to fix. From task to release. Of course, the process might be complex, with iterations, reviews, forks and branches. In the end, those are just the wheels of train taking the project to where it needs to be. Ideally, cards just speed across the kanban, left to right.

 

Work on a software project is often linear. Point A to point B.

 

This kind of progress is easy to understand and measure: when the work is complete, the goal will be achieved.

 

Now let's consider a specific scenario: the urgent task. It could be a bug fix, an important client request. Whatever. We just need to get to Point B, now. Speed is important now, so we are willing to cut some corners.

 

Speed is important now, so we are willing to cut some corners.

 

This is where technical debt comes in. In order to accomplish our goal quickly, we incurred some technical debt: the corners that were cut. "I know this is bad, but we don't have time to do it right. We can come back to it..."

 

This is also where we run into a contradiction of sorts. Going from A to B was meant to make things better. And it did. The bug was fixed. The feature was delivered. That part is good, for the business, for the code base, for everyone. But in obtaining this positive result, we also made things worse. This is the contradictory part. How is it possible to improve the code while making it worse?

 

Just about anyone involved in software has observed a scenario like this one. It obviously happens, so if there is a contradiction, it's because our ideas about it need to be adjusted.

 

This is why concepts like "Technical Debt" and "Code Health" are important. And I would suggest that they require us to consider progress in two different dimensions. Let's go back to our arrows and points A and B.

 

Let's go back to our arrows and points A and B.

 

Depending on how we accomplish the move from A to B, we will end up at a different place in the second dimension, somewhere between "Worse" and "Better".

"Worse" and "Better" refer to the state of the entire code base. "Worse" means that it will be harder, riskier, more expensive, to make the next changes, from B to C, for example.

 

Or, maybe we take our time and really try to do this right. As a result, we improve the code base along the way.

 

As a result, we improve the code base along the way.

 

In both cases, we get to the destination. The bug is squashed, the feature is released, the problem is solved. The result of our actions is not the same, however. In one scenario, we've either made any future work more difficult, expensive or bug-prone. In the other scenario, it future changes will be more pleasant and less expensive; the code base will be easier to maintain. (Real life is more subtle of course, but you get the idea.)

 

So progress and improving or deteriorating the Code Health of your code, adding to or removing from your technical debt are not contradictory. They are two different dimensions of a single action. And this is why a tool like CodeScene can help, by providing a metric for    this second dimension to your work.

 

Keep on reading! Find out how refactoring recommendations can be based on your own code. 

Joseph Fahey

Elements Image

Subscribe to our newsletter

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Semper neque enim rhoncus vestibulum at maecenas. Ut sociis dignissim.

Latest Articles

University of Antwerp uses CodeScene in Re-engineering Course

University of Antwerp uses CodeScene in Re-engineering Course

Master-level Software Re-engineering course uses CodeScene to restructure existing software. Interview with Dr. Henrique Rocha, University ...

CodeScene helps identify technical risk and prioritize actions to mitigate it

CodeScene helps identify technical risk and prioritize actions to...

Peter Caron, former SVP Global Engineering at HelloFresh shares his insights on leveraging CodeScene to prioritize efforts of the developme...

Ework Group uses CodeScene to Navigate Challenges of Distributed Software Development

Ework Group uses CodeScene to Navigate Challenges of Distributed...

Ework Group uses CodeScene for unbiased development insights, assessing performance and risks. Daniel Asvelius, Ework's CIO, shares insight...