• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
(Managing) Technical  Debt
 

(Managing) Technical Debt

on

  • 332 views

 

Statistics

Views

Total Views
332
Views on SlideShare
332
Embed Views
0

Actions

Likes
0
Downloads
22
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    (Managing) Technical  Debt (Managing) Technical Debt Presentation Transcript

    • (Managing) Technical Debt (Steve McConnell) Gustavo Muñoz VP & CTO, Grupo Expansión (A Time Inc. Company) July 4, 2013 Thursday, July 4, 13
    • 1992, Ward Cunningham “Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Thursday, July 4, 13
    • 1992, Ward Cunningham Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand- still under the debt load of an unconsolidated implementation, object-oriented or otherwise”. Thursday, July 4, 13
    • Technical Debt "A design or construction approach that's expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)" —Steve McConnell Thursday, July 4, 13
    • Technical Debt The term technical debt is defined as the cost to improve technical quality up to a level that is considered ideal. The interest of technical debt is the extra cost spent on maintaining software as a result of poor technical quality. Technical debt grows over time if not resolvedbecause the quality of changes performed on top of systems of poor technical quality tend to be poor. Thursday, July 4, 13
    • Maintenance vs Tech Debt Maintenance encompasses activities such as adding new functionality and fixing bugs. Maintenance is different from technical quality repair in that it involves visible changes and their impacts are immediately visible (e.g., fixing bugs or adding new features). Extra effort spent on retrofitting new functionality or fixing bugs are examples of interest on technical debt. Thursday, July 4, 13
    • Technical Debt Example “Guys, we don’t have time to dot every i and cross every t on this release. Just get the code done. It doesn’t have to be perfect. We’ll fix it after we release”. Thursday, July 4, 13
    • Technical Debt Example “We don't have time to reconcile these two databases before our deadline, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship.” Thursday, July 4, 13
    • Why Discuss Technical Debt Helps to educate technical staff about business decision making. Helps to educate business staff about technical decision making. Raises awareness/transparency of important issues that are often buried. Thursday, July 4, 13
    • Why Discuss Technical Debt Allows technical debt to be managed more explicitly. The analogy is rich and produces numerous insights Thursday, July 4, 13
    • A tiny video (4:44) http://www.youtube.com/watch?v=pqeJFYwnkjE Thursday, July 4, 13
    • Reasons to Take on Technical Debt The Business View Shortening time to market Preserving startup capital Delaying development expense Business staff tend to be optimistic (or ignorant) about the benefit of taking on the debt and about the costs of carrying the debt Thursday, July 4, 13
    • Reasons to Take on Technical Debt The Technical View Debt can create a vicious circle Thursday, July 4, 13
    • Reasons to Take on Technical Debt The Technical View Technical staff tends to be pessimistic about the benefit of taking on the debt and about the costs of carrying the debt Attitude toward debt can be religious Attitude toward debt can be aesthetic Thursday, July 4, 13
    • Business vs. Technical Viewpoints Business staff tends to be optimistic about debt Technical staff tends to be pessimistic about debt These attitudes are often not conscious Debt is a tool, neither inherently good nor bad The Technical Debt metaphor gives these two groups a constructive way to approach some important discussions Thursday, July 4, 13
    • How Much Debt is Enough/Too Much? There is no one right answer for business debt, and there is no one right answer for technical debt Technical staff’s attitude is sometimes extreme: “zero debt” Decreasing velocity can be an indicator Thursday, July 4, 13
    • How Much Debt is Enough/Too Much? Business staff tends to have a higher tolerance for technical debt (but weaker memory of it) Work is required to ensure the organization remembers its debt decisions Thursday, July 4, 13
    • Technical Debt Landscape Thursday, July 4, 13
    • Tracking Debt All “good debt” can be tracked (by definition) Log as defects Include in product backlogs Monitor project velocity Monitor amount of rework Thursday, July 4, 13
    • Things to do (whole story) Green: new features Red: defects Yellow: arch elements Black: technical debt Thursday, July 4, 13
    • Ways to measure Debt Total of debt in product backlog Maintenance budget (or fraction of maintenance budget) “Aged” customer work backlog Measure debt in money, not features, e.g., “50% of R&D budget is nonproductive maintenance work” Thursday, July 4, 13
    • What can we do with TD Thursday, July 4, 13
    • “Reification” The main value of “technical debt” is reifying a concept that’s otherwise too intangible to be handled well Thursday, July 4, 13
    • What can we do about it? Talk with technical staff about it Communicate to business staff the implications of it Measure the amount of it Make explicit decisions about whether we should take on more of it Thursday, July 4, 13
    • What can we do about it? Get input from the business about whether the business believes we should have less or more of it Strategize how to avoid it Track it Make explicit decisions about when and how to reduce it Thursday, July 4, 13
    • Thanks... and sorry! Thursday, July 4, 13