Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Published on
Everyone agrees that technical debt is a burden on software innovation that we would rather avoid, and certainly clean up whenever possible. However, in most organizations, people don't prevent technical debt nearly as much as they should, and they don't ever get the time to clean it up. Why, then, if there are clear incentives to deal with technical debt, is it a rampant problem?
In this session, we will focus on how to deal with technical debt on several levels, including the individual developer, the team, the software value stream, and the larger organization. While technical debt may manifest itself in a developer's IDE, the problem starts long before the developer decides to copy and paste some code, or creates an overly-complex and under-documented class. The pressures on teams and individuals to take on more debt than they should come from many sources. Therefore, the solutions to the technical debt problem must extend beyond the team.
Login to see the comments