component and inter-component behavior when the application functionality meets a minimum standard of satisfaction for its users.” Chris Sterling (Managing Software Debt: Building for Inevitable Change)
that is unreasonable, they are bound to cut corners in order to meet the expectations of management. Reasons: - Scope Creep - Third-party estimates - Change in team makeup - Artifact of the estimation process - Late integration
codebase makes making changes much more error-prone and timely. Reasons: - Lack of experience on the part of team members - Copy-and-paste programming - Conforming to existing software’s poor design - Pressure to Deliver
It is unlikely that you will design the perfect system to accommodate any and all changes to a codebase. Reasons: - Using Waterfall Development - Users expectations change - Improvements in underlying technologies - Adopting new development practices
debt that can be fixed quickly. Effective Acknowledgment of Short-term debt: - Pay off the technical debt immediately - Use of runtime exceptions Examples: - Code coverage for a method - Small Refactorings
runtime exception exactly where the technical debt is. Useful if the fix to the technical debt does not drastically increase the amount of time allotted for the original estimate of work.
debt is so large that paying off the debt is a task in and of itself. This is classified as long term debt. A great way to effectively manage long term debt is to maintain a list of Technical Debt tickets in the product backlog, alongside feature and bug tickets. Examples: - Code Coverage for an entire Class - Large Refactorings - Process Optimizations
of technical debts tickets in the backlog takes Technical Debt management to a whole new level as members outside of the development team will now be made aware of the technical debt. Building team awareness will greatly aid in the management of technical debt as long as developers properly convey the what technical debt is and why it should be managed.
Project Manager takes on most of the burden of communicating with business stakeholders and Developers in the best place to balance the amount of time allocated to paying off long term debt. It is up to the developers to ensure that PMs have an accurate understanding of why the completion of these technical debt tickets is vital to the health of the project.
It is up to the developers of the codebase to properly groom the Technical debt tickets that have been backlogged and convey the importance of of these tickets to the PM so that they are not deprioritized. Your technical project should only maintain one list of work.
of technical debt tickets should be continuous. This fits in well with Agile software development as technical debt tickets should be continuously included in new sprints.
pioneered the use of technical debt tickets. We simply started creating tickets and assigned them a new Epic labeled “Technical Debt”. Being the first team to adopt such a practice, I was skeptical of how well the PMs, along with our iOS counterparts, would react to such a change.
understood the importance of addressing such tasks. *Fun Fact* It was received so well from our PMs that the PMs created a ticket for our iOS counterparts to create technical debt tickets.
up to the developers on that project to promote the importance of effectively managing technical debt by either fixing it immediately, using runtime exceptions to fix it in a few minutes, or creating a ticket in the Technical Debt Backlog. It is also up to the developers to effectively collaborate with other members of the team so that everyone has a good understanding of the importance of a technical debt backlog.
tickets will aid in our TDD initiatives as (mentioned earlier) technical debt tickets are great ways to track large refactorings. - The continued adoption of technical debt tickets by developers will continue to build awareness of Technical Debt at Fuzz in general. Discussion: - What do you guys think? How do other projects at Fuzz manage technical debt? - Specifically since Fuzz is an Agency and some of our projects have a finite end date, do you think managing Technical Debt is as important on such projects?