Technical Debt

Technical debt is a metaphorical term that describes the implied cost of additional rework caused by choosing an easy solution instead of using a better approach that would take longer.

Resource Allocation Choices

• New Features: Can increase income but may add to technical debt
• Maintenance: Essential for managing existing debt; includes bug fixes and system optimizations

Maintenance Categories & Technical Debt

• Corrective: Fix bugs/problems
• Technical debt often leads to an increased need, as earlier shortcuts or suboptimal decisions result in defects that must be corrected later
• Adaptive: Change to fit the new environment
• Technical debt can make adaptive maintenance more challenging and time-consuming, as the codebase may not be structured optimally to accommodate such changes
• Perfective: Improve performance or maintainability
• Direct impact as accumulated debt often involves aspects of the software that are inefficient or poorly structured, requiring additional work to enhance and optimize
• Preventive: Detect and correct latent problems before they become actual problems
• Technical debt is often a source of these latent problems. Preventive maintenance can be seen as an approach to managing and reducing technical debt by proactively addressing areas of the code that are likely to cause problems in the future.

Scenarios

The development group used no coding standard, ambiguous variable names, and had little testing

A design was chosen for the application, but after release, it was found not to be able to support new features

A low-quality database was used in the initial release due to the developer's limited experience. This led to numerous performance issues later on.

Technical Debt

• Unintentional - The design approach does not work with unexpected or changing requirements
• Intentional - Optimize short-term goals at the expense of the future

Unintentional Technical Debt

• Design choices create errors
• Mismanaged developer takes a shortcut that doesn't work
• Software is purchased (source) that has more problems than was thought

Intentional Technical Debt

• Leaving in a problem to get a release out earlier
• Gluing together parts of systems instead of merging them
• Substandard parts of the system are accepted to release the project sooner

Time Period

• Short-term technical debt
• Long-term technical debt

Creating Technical Debt

• Time to market
• Startup capital
• Delaying development expenses

Management Strategies

• Identification and Tracking: Recognize when and where debt occurs or is identified
• Categorization and Documentation: Classify and record debt for transparency and understanding
• Prioritization and Resolution: Focus on high-impact debts; integrate resolutions into development cycles
• Communication: Ensure organization-wide awareness of the debt and its implications

Observations

• Small technical debts add up but are inconspicuous
• Large technical debts are very well-known by the organization
• So which is preferred?

Managing Technical Debt

• Have to trace when it occurs or when it is discovered
• Requires naming and categorization
• Implications must be made clear to other groups