Often we find it difficult to incorporate any changes in a software project during later phases of its development, or during post-delivery maintenance. Primary reason for this is inflexibility in design and code which makes it difficult for changes to be incorporated. This inflexibility substantially increases the cost of making changes and this metaphor has been termed as Technical Debt.
While Technical Debt cannot be eliminated completely, its burden needs to be reduced. Many agile practitioners have suggested some practices to avoid or eliminate Technical Debt.
In this session I shall discuss about a method to get relief from Technical Debt and talks about nine proven practices that a developer can follow to minimize Technical Debt. These practices help to:

  • Change the coder's mindset so that they should use technical practices i.e. various refactoring techniques to reduce technical debt in code and design
  • Developers to plan and manage the time to pay down the debt i.e. determine your living budget
  • Take minimal technical credit in design and code

These practices have been used and found to be effective when implemented in projects which will be used as a case study.


Outline/Structure of the Talk

Understnading on Techical debt
Various types of technical debt
Importance of technical debt in software development
Practices to minimize the technical debt

Learning Outcome

This session is going to answer below questions:

What is technical debt?
Why is it difficult to incorporate any changes in a software project during later phases of its development, or during post-delivery maintenance?
Why is it difficult to maintain the code along with quality in longer run?
Why do we need technical debt?
Why cannot we eliminate it completely?
How can we minimize the technical debt?
What are some practices to minimize technical debt?

Target Audience

Software Developer, Programmer, Team/Tech Lead, Project Lead, Module Lead, Project Manager, Delivery Manager

schedule Submitted 6 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Sachin goel
    By Sachin goel  ~  6 years ago
    reply Reply

    Hi Vinay- the focus is so much on the developer here. in your real world experience, have you seen that working effectively if not supported by other stakeholders. do you also have some suggestions for developers on how to influence other stakeholders( guess this question is in line with Venkat comment).

    thanks - sachin

    • Vinay Krishna
      By Vinay Krishna  ~  6 years ago
      reply Reply

      Hi Sachin - One of 9 practices talks on similar line where it explains how it could show the improvement to others. Eventually, this can be used to influence other stakeholders.

      As far as extra time and priotization is concerned it's not so simple, nevertheless that also I shall cover. We need willingness and awareness among developers on technical debt. As per my experience and observation, first developer need to influnce himself rather than others. Looks confusing or theoretical!!! I firmly belief I'll be able to clear all these queries in my session.

      Thanks for your message and time!

  • Venkatraman L
    By Venkatraman L  ~  6 years ago
    reply Reply

    Hi Vinay, are you also planning to cover how you can get the sponsor for the technical debt as many times it gets depriortiized by the product features ? What is your take on such scenarios ? Who needs to educate the stakeholders ?

    • Vinay Krishna
      By Vinay Krishna  ~  6 years ago
      reply Reply

      Hi Venkatraman - Thanks for your comment! This talk is from developer's perspective, I could discuss on the points that you have mentioned but based upon participants interest. However primary focus shall be on minimizing technical debt from a developer's perspective.

      • Venkatraman L
        By Venkatraman L  ~  6 years ago
        reply Reply

        Thanks Vinay. Understood.

  • Joel Tosi
    By Joel Tosi  ~  6 years ago
    reply Reply

    Hi Vinay,

       I would like to see more time on the practices and less time on the 'what is technical debt' / background.  Could you help me understand the breakdown from a time perspective?




    • Vinay Krishna
      By Vinay Krishna  ~  6 years ago
      reply Reply

      Hi Joel - Its max 20-25 percent of time on "whats technical debt" and rest on the practices. This may cary based upon partcipants.



  • Savita Pahuja
    By Savita Pahuja  ~  6 years ago
    reply Reply

    Hi Vinay, Would be good if you can give more information about the practices.

    Is it a hands on sessio or only presentation ?

    • Vinay Krishna
      By Vinay Krishna  ~  6 years ago
      reply Reply

      Hi Savita,

      Thanks for your comments! Its a presentation based upon case study/real time data/examples. These practices are effective in order to change the coder's mindset and also help developer to successfully use already existing and proven technical practices to minimize technical debt.




      • Savita Pahuja
        By Savita Pahuja  ~  6 years ago
        reply Reply

        Hi vinay thanks for the response. I am looking for some examples. It would be great if you can update the proposal with some examples.

        • Vinay Krishna
          By Vinay Krishna  ~  6 years ago
          reply Reply

          Hi Savita - I have described further in the abstract on these practices at high level.

  • Liked Vinodhini

    Vinodhini / Thushara Wijewardena - Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile

    20 Mins
    Experience Report

    Here is a case study of how agile outsourcing can be practically applied even when the business domain is very complex and alien to offshore teams.
    The example is a project in which Exilesoft provided for a leading Norwegian producer of Robotic warehousing solutions. The project involved transforming their legacy application, produced using multiple suppliers and methods, into a newly cast application solution. This project also had its own share of typical challenges.

    • Lacked definitive and reliable documentation,
    • Domain knowledge was limited to a few very busy individuals,
    • Development and redeployment could not interrupt attention to current customers,
    • Complexity was high and design was fragmented, and
    • Focus heavily invested on current product and customer support

    These limitations along with the lack of understanding of agile methods strongly suggested the use of a method adaptive in nature, and not heavily vested in large inflexible legacy elements.
    We commenced the engagement with two pivotal elements; client awareness (agile orientation) and a roadmap of committed involvement. To lay credibility this had to be backed up with proven result delivery in the very early stages. It allowed for flexible adaption, and the creation of an atmosphere that fostered client interest.

    During this session, we will take the audience through a small video clipping of such a warehouse. We will elaborate how the customer and offshore developers worked together using agile in a highly integrated team collaboration model to achieve success within a very short time frame.

    The session will cover the following key areas:

    How such projects can be initiated

    - What type of team model and contract type we used

    - How we did the agile transformation with the customer

    - How the roles were assigned between offshore and onshore team members

    - To improve remote collaboration the tools and techniques we used

    - Techniues learned to get teams up to speed with the new domain

    - As we go along, the process changes we identified and implemented to make things work better.

    - Agile engineering practices and team dynamics that helps in such situations

  • Liked Shamira Dias


    Shamira Dias
    Shamira Dias
    Delivery Manager
    Exilesoft Pvt Ltd
    schedule 6 years ago
    Sold Out!
    45 Mins
    Case Study

    A Scandinavian client who had bad experience with offshoring came to our doorstep. He was somewhat skeptical about offshoring but was willing to take a second chance. We had to be vigilant right from the start, it was a learning experience, a new project a suspicious customer and a watchful management… how did we handle the situation? The obstacles experienced by the team are universal. They are applicable to any team attempting to convert a client from waterfall to Agile.




    How did we initiate the project - what was the way forward?

    Were we cautions or did we plunge right in?

    Did we play by the rules or did we make our own?

     The learning experience of this talk is a step by step directive of how the above challenge was undertaken. The audience will be introduced to four attributes identified by the team as the four pillars of offshore agile rollout, namely being resilient, being innovative, being pro-active and being cooperative. By the end of the session the audience will understand

    (i)                 how to be resilient with the product owner, what are the essential practices

    (ii)               the habit of being innovative, what needs to be incorporated

    (iii)             the secret of pro-activeness, and taking control

    (iv)             the importance of being cooperative, how to instigate productive discussions

    Following this case study the audience will be able to apply the four pillars of offshore agile rollout to challenges faced with their own clientele.