Recently I was in  conversation with couple  of our customers  on the topic of  Agile Methodology and the concept of Technical debt in detail. I also happened to meet few project teams during my reviews where I see that the project milestones are missed due to technical debt.  I am sharing below my thoughts on this topic.

What is Technical debt?

Technical debt is something you have to pay later on for the unfinished work in the software product. For example,  if you have hardcoded a lot of stuff due to the crunched schedule to take care of Time to Market, you have incurred Technical debt.  You will have to pay this debt, when you try to maintain or update the software later on.

What causes Technical debt?

Business pressures: Time to Market pressures.  Quite often we hear from our customers: We need to release this product on July 1^st.  In a time crunched window, the software development teams usually do not have the luxury of following the right processes required for software development.  Activities like documentation, collaboration, writing test suites, code reviews get postponed or never done.  Sometimes, the situations becomes worse: requirements  gets added/keeps changing but the release date does not move! This is a typical scenario where technical debt is incurred. When Time to market becomes the only goal, no one pays attention to things like following the right coding standards.

Of course, Business pressures are not the only cause. Technical debt is incurred even without any business pressure. A junior programmer writing a bad code, a poorly done design, undocumented code are all causes of technical debt. Similarly lack of understanding of software development processes, poor requirements with no common definition of done, lack of automation in build & release, lack of automation in testing  contribute to the technical debt. If the requirements keep evolving and teams do not refactor the code periodically, technical debt gets piled up.

Does adopting a specific methodology (eg: Agile)  cause Technical debt?

No. Technical debt has been existing ever since software development is happening   whatever be the SDLC methodology.

Some of our customers focus only on Time to Market & more features per release. Project timelines do not allow us to follow all the software development processes. How do we deal with this?

We need to get into discussion with our customers.  They have hired us with the trust that we bring in the best practices of software development. It is expected out of us as software professionals,  to highlight and quantify technical debt.  Usually trade-offs will have to happen between short term goals (time to market) and long term goals (updating the software with new features with ease). If we bring in a business perspective to the technical debt concept, customers will be willing to listen to us. Once customers agree, then it becomes easier to deal with technical debt. Either we can plan a sprint to take care of technical debt (eg: refactoring the code, writing test case suites etc) or take care of technical debt in an incremental fashion in every sprint.

Summary:  Technical debt is something similar to health debt. We need to do our exercises, follow the right food habits, sleep well on a daily basis. If we do not follow a healthy life style, we are incurring health debt which we have to pay later in some form: sickness, medical bills, productivity loss, unhappiness etc. Similarly, if  we do not follow healthy software development processes, we incur technical debt which has to be paid later in the form of production bugs, costly maintenance releases, missed milestones, team burn outs, customer frustrations.  Let us ensure we do the right things and help our customers do a conscious choice to balance their short-term and long-term goals.

 

Read complete blog