Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Information Technology, Innovation
Technical Debt Management
I was puzzled by the title of an article that alludes to the high cost of having low technical debt. Unfortunately, the author did not answer that question, focusing instead on fixing technical debt through new technology.

The newly minted PMI-ACP in me thinks that switching technology is overkill for reducing technical debt. Shouldn't re-factoring be enough?
Sort By:
There is a big missunderstanding about technical debt outside there. I can talk about that because I worked with the people that "invent" the concept. Unfortunatelly sometimes is taking as a mean to justify the dream about agile is about deliver fast. First of all, agile was created with quality as one of its pillars so no technical debt or similar is accepted. But in quality theory you have two key concepts: quality and grade. The key is getting a balance between quality and grade and like eveything in quality it is an strategical decision. You have to decide to create products with low quality and high grade or the contrary. Products with low quality and high grade you will find a lot mainly in software industry as an example. So, technical debt is closely related to grade concept. How you manage that is up to you in the framework of strategical decisions thru quality. Re-factoring or all other techniques can be applied but if and only if everything is considering until maintenace framework (preventive-corrective-adaptative).
Stéphane -

It comes down to the magnitude of the technical debt. Yes, for small volumes of it relative to the overall "size" of the solution, refactoring works well.

But imagine a legacy application developed one or two decades back which has been band-aid'ed frequently. In such cases, refactoring out all technical debt might actually cost more than a replacement, especially when the poorly maintained code is combined with a lack of automated regression testing.

Actually, that is another good example of technical debt - large, complex technical solutions with no automated regression test repositories. The cost of creating these from scratch to provide sufficient coverage is way more than any company would be willing to spend money on.

Kiron
...
1 reply by Adrian Carlogea
Mar 07, 2020 8:22 AM
Adrian Carlogea
...
I have started my career as a software developer and as a technical expert in this field I don't think that replacing an application just because the current one has a lot of technical debt in it is a good idea or even cheaper than refactoring.

If you want to do some bigger changes in a certain area then the best solution is to refactor that part of the application so you can easily develop features related to it.

Trying to refactor the whole application, for me as a developer, makes no sense. Also it makes no sense to replace the application just because it has technical debt. If the new application is written under big pressure from management to finish faster then it can result in having even more technical debt that the legacy one.
Thank you again, Sergio and Kiron, for your provocative and thoughtful replies.
...
1 reply by Sergio Luis Conte
Mar 07, 2020 7:42 AM
Sergio Luis Conte
...
You are welcome. Is a topic I am facing from years including today in my actual work place. It is hard, at least in my experience, to help people to understand that if they like to work considering technical debt then it must be done as part of the strategy they want to put in place. If not, is the same than cost of quality.
In software development technical debt refers to code that is hard to maintain and further develop. Technical debt is something that only developers can understand and "feel".

Non-developers as well developers who don't directly work with a specific peace of code can't tell it that code suffers of technical debt.

Also if some developers have worked with a product for a very long time they would get used to it and they would not "feel" the technical debt anymore, at least not at the same intensity. For new developers however it would be very hard to start working with code that suffers of technical debt.

For managers it is hard to manage technical debt as they can't see it unless they are hands-on and they try to work with the code themselves.
Mar 06, 2020 5:06 PM
Replying to Stéphane Parent
...
Thank you again, Sergio and Kiron, for your provocative and thoughtful replies.
You are welcome. Is a topic I am facing from years including today in my actual work place. It is hard, at least in my experience, to help people to understand that if they like to work considering technical debt then it must be done as part of the strategy they want to put in place. If not, is the same than cost of quality.
Mar 06, 2020 4:23 PM
Replying to Kiron Bondale
...
Stéphane -

It comes down to the magnitude of the technical debt. Yes, for small volumes of it relative to the overall "size" of the solution, refactoring works well.

But imagine a legacy application developed one or two decades back which has been band-aid'ed frequently. In such cases, refactoring out all technical debt might actually cost more than a replacement, especially when the poorly maintained code is combined with a lack of automated regression testing.

Actually, that is another good example of technical debt - large, complex technical solutions with no automated regression test repositories. The cost of creating these from scratch to provide sufficient coverage is way more than any company would be willing to spend money on.

Kiron
I have started my career as a software developer and as a technical expert in this field I don't think that replacing an application just because the current one has a lot of technical debt in it is a good idea or even cheaper than refactoring.

If you want to do some bigger changes in a certain area then the best solution is to refactor that part of the application so you can easily develop features related to it.

Trying to refactor the whole application, for me as a developer, makes no sense. Also it makes no sense to replace the application just because it has technical debt. If the new application is written under big pressure from management to finish faster then it can result in having even more technical debt that the legacy one.
Dear Stephane,

This goes back to ensuring that your Information Systems match and exceed the business requirements. Anything else it just wasteful.

Like every department in an organization, IT has an annual budget that is drawn up in advanced where scoped project costs and fixed recurrent costs are included.

Computers and information technology were originally brought into organization in order to improve efficiency, that is a better, quicker and cheaper way of completing a process.

As a result this drove efficiency, reduced implementation costs and recurring cost of implementing a process.

As a result, IT was seen as doing such a good job that it got its own department and a annual budget.

So now IT was expected to continuously implement new process to increase efficiency and production.

However this initial rapid increase in efficiency has been seen to taper of in the recent decades and now efficiency and cost reduction is found by using shared services, ubiquitous devices, bring your own device policies and cloud enabled web technologies.

In some way IT has become a victim of its own success and now has reached a technical glass ceiling.

So now the term Technical debt has been introduced which is a piece meal approach to a problem using the available resources and timeline.

So the way to avoid getting hung up on this 'problem' it to work out the cost implication to the business by implementing a solution that maybe a overkill or just solve the immediate problem.

If the business requirements are met and the problem is not business critical them all you are doing is making a decision based on the present business requirements rather than what may happen in the future.

A risk assessment on the problem may make the approach cost prohibitive and not necessary.

Daire
I agree with Sergio

Please login or join to reply

Content ID:
ADVERTISEMENTS

"If nominated I will not run, if elected I will not serve"

- General William T. Sherman