Understanding and Addressing Technical Debt

Understanding and Addressing Technical Debt

(This is an intro, the complete article will follow shortly after the weekend)

In software development, technical debt is?the implied cost of future reworking... when an implementation prioritizes quickness or convenience of implementation, while compromising quality.


Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g. as a proof-of-concept) is required to move projects forward.

  • Ongoing development, long series of project enhancements over time renders old solutions sub-optimal.
  • Insufficient up-front definition, where requirements are still being defined during development, development starts before any design takes place. This is done to save time but often has to be reworked later.

So... what's the problem?

But the interest we pay may be grossly underestimated, and implications a lot larger than we expect.

At some point, a project may not be able to find solutions when it comes across any issues, because of the past accumulated debt.


Like monetary debt, if not repaid, it can accumulate interest, making it harder to implement changes.


Can it be avoided?

There are some measures one can take to avoid it. We will look more into them soon in the upcoming continuation & conclusion (and beginning to a lot more possibilities to better quality) to this article.

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."

(references: wiki, internet images)


Sanjay Mysoremutt

Engineering Software with care

1 个月
Saurabh Bhatnagar

Influential Engineering Leader Cloud-SRE-DevOps at Epsilon Publicis | Passionate Speaker | Opinions expressed are solely my own not the opinions of my employer | Working Hybrid | Alumini Oracle, PeopleSoft, Hexaware, HP

2 个月

We also see tech debt bucketing of real bugs in any case error budgets should be used to account for them

Nirmalya Sengupta

Your CTO on hire | Product Managers' Tech-comrade-in-arms | Hands-on Server-side Rust, Java, Scala programmer |

2 个月

I am happy to hear that you are taking up this topic for elaboration; one more time after the hundred of thousandth time (perhaps), it has been taken up in the past. I myself, have done. However, I appreciate your effort because the topic needs repetition. My realization has been that finally, it all depends on the stakeholders: who has / have real interest in seeing the software, being useful and successful (and therefore, are putting money). It is they who have to sit up and grasp that fact that known defects are a burden on the users and developers, and in turn, on the money bank. A significant number of regular business software , if not the significant majority of them, falls in this category. After all, most of them are, in their core, CRUD applications, aren't they? Then, what's the big deal really? I will wait for your upcoming installments and comment, if I think my comments will add any value to the discussion.

Bibin Radhakrishnan

Progress not perfection!

2 个月

If software is an engineering field and technical debt is allowed then it should be allowed in other fields of engineering too or software shouldn't be categorised in the field of engineering because of the bugs allowed. Imagine having the amount of bugs software has on a bridge or a road. It would be considered unusable. The majority of people working for software companies only fix any bug that pops up and they have no idea why it popped up. Im not saying this to insult the software field but to ensure that software should either have a limit to the the number of bugs like a bridge or a road or a car or any other field of engineering where there is a loss to life in the event of an issue and the Architects are issued legal notices. It is also to be noted that software does not take lives yet but it does bring the professional life to a stand still with just one update. That's how weak the system is. If the software community were to accept this and indicate that this is not a field of engineering since we cannot maintain the same level of quality like other engineering fields it would be a good place to start. If you would like this to change I would love to be a part of it. #myexperience and #myexplorations.

要查看或添加评论,请登录

Sanjay Mysoremutt的更多文章

  • How do we deal with technical debt?!

    How do we deal with technical debt?!

    (references: wiki, internet images) As we saw in the introduction to technical debt, new features that otherwise…

    4 条评论
  • Work is an opportunity

    Work is an opportunity

    There is a story of the Emperor Akbar and his (reportedly fictional) brilliant minister Birbal, a very wise advisor…

    6 条评论
  • Somewhere out there... is the Chandrayaan-3 Rover

    Somewhere out there... is the Chandrayaan-3 Rover

    ?? to the amazing dedication of ISRO - Indian Space Research Organization

  • the ergonomic scientist

    the ergonomic scientist

    [Sep, 2006] One of my colleagues had sent a scary mail of photos of carpal tunnel surgery. That was definitely a mail…

  • my rsi story

    my rsi story

    [July 14th, 2003] This is a record based on some memories, of my RSI and all its consequences. If anybody already has…

    1 条评论
  • A Code Retreat - Learning with Ensemble Programming

    A Code Retreat - Learning with Ensemble Programming

    The Global Code Retreat this year is again conducted online, and described in more detail on the Nelkinda Software…

社区洞察

其他会员也浏览了