Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Crystal Ball to Prioritize Technical Debt

A Crystal Ball to Prioritize Technical Debt

The technical debt metaphor has taken the software world with storm. No wonder, since software projects have their fair share of challenges. Most organizations find it hard to prioritize and repay their technical debt. The main reason is due to the scale of modern systems with million lines of code and multiple development teams; No one has a holistic overview. So what if we could mine the collective intelligence of all contributing programmers and start to make decisions based on data from how the organization actually works with the code? This session introduces one such approach with the potential to change how we view software systems.

Adam Tornhill

April 28, 2017
Tweet

More Decks by Adam Tornhill

Other Decks in Programming

Transcript

  1. @AdamTornhill

    View full-size slide

  2. “Like a financial debt, the technical debt incurs interest payments,
    which come in the form of the extra effort that we have to do in
    future development”
    Questioning Technical Debt
    https://martinfowler.com/bliki/TechnicalDebt.html
    @AdamTornhill

    View full-size slide

  3. Interest Rate Is A Function Of Time
    http://i.imgur.com/a8Xo4Hp.png
    @AdamTornhill

    View full-size slide

  4. All Technical Debt Isn’t Equal
    @AdamTornhill

    View full-size slide

  5. @AdamTornhill
    Most Technical Debt Isn’t Technical

    View full-size slide

  6. There’s A Strong Link Between
    Technical Debt And The Organisation
    @AdamTornhill

    View full-size slide

  7. Wish List: Information to Prioritize Technical Debt
    @AdamTornhill
    Where’s the Highest Interest Rate?
    Does the Architecture Support the way our System Evolves?
    Any Productivity Bottlenecks for Inter-Team Coordination?

    View full-size slide

  8. Collective Intelligence
    Social information
    Time
    @AdamTornhill
    Uncover Evolutionary Patterns In A System
    Frequencies

    View full-size slide

  9. Hotspots
    Where’s The Highest Interest Rate?

    View full-size slide

  10. Hotspots - A Tool To Prioritize
    @AdamTornhill

    View full-size slide

  11. Code Complexity
    Code Change Frequency
    Hotspot
    @AdamTornhill

    View full-size slide

  12. Hotspots - A Tool To Prioritize
    Hotspots
    Hotspots

    View full-size slide

  13. All Code is Equal
    …but some Code is more equal than others*
    * Sorry, George Orwell

    View full-size slide

  14. Why Hotspots Work
    1 Year in Roslyn (C#, VB) 6 Years of Erlang 12 Years of Ruby on Rails
    Each file in the system
    Change Frequency
    Reference: Your Code as a Crime Scene, ISBN:1680500384
    Prioritize improvements here!
    Ignore the long tail

    View full-size slide

  15. Case Study:
    @AdamTornhill

    View full-size slide

  16. gc.cpp
    @AdamTornhill

    View full-size slide

  17. File Level Hotspots Function Level Hotspots
    X Ray
    Recommended functions to improve.
    Hotspots X-Ray

    View full-size slide

  18. Read More:
    Function-Level
    @AdamTornhill

    View full-size slide

  19. Normalization of Deviance
    @AdamTornhill

    View full-size slide

  20. Supervise your Complexity Trends
    @AdamTornhill
    Warning Sign!
    Refactoring
    Increases again

    View full-size slide

  21. Hotspots Summary
    Hotspots find the code with the highest interest rate.
    Hotspots work because all code isn’t equal.
    Supervise the Complexity Trend of your Hotspots.

    View full-size slide

  22. Evaluate Your Architectural Patterns
    Does the Architecture Support the way our System Evolves?

    View full-size slide

  23. Code is Auto-Destructive Art
    @AdamTornhill

    View full-size slide

  24. Your System’s Tipping Point?

    View full-size slide

  25. DRM Shared
    DRM/AMD

    Specify Your Logical Components
    @AdamTornhill

    View full-size slide

  26. Identify Hotspots on a (Micro)Service Level
    @AdamTornhill

    View full-size slide

  27. FuelInjector
    Temporal Coupling
    Diagnostics
    Combustion
    Commit #1 Commit #2 Commit #3
    Time
    @AdamTornhill
    Read More: http://www.empear.com/blog/software-revolution-part3/

    View full-size slide

  28. Model
    Controller
    View
    Services
    ORM
    Repository
    SQL
    Layers: A Separation of Concerns
    General Observation:
    30-70 % of all commits touch multiple layers
    @AdamTornhill
    Change Coupling

    View full-size slide

  29. Supervise The Change Coupling Between Services
    @AdamTornhill
    Temporal Coupling
    (potentially across
    repository boundaries)

    View full-size slide

  30. The Microservices Shotgun Surgery Pattern
    @AdamTornhill

    View full-size slide

  31. Tools
    Evolution Radar
    http://reveal.inf.usi.ch/web/dambros/tools/evoradar.php
    CodeScene: free for open source (commercial)
    https://codescene.io/
    Moose Platform: open source platform
    http://www.moosetechnology.org/
    Code Maat: open source, text-only (GPL)
    https://github.com/adamtornhill/code-maat

    View full-size slide

  32. Architecture Summary
    Identify your Architectural Hotspots.
    Know your System’s Tipping Point.
    Use Temporal Coupling to Evaluate your Architecture.

    View full-size slide

  33. Meet The Social Side of Your Code
    Any Productivity Bottlenecks for inter-team coordination?

    View full-size slide

  34. Process Loss
    Process Loss
    The Potential Productivity
    Individual Contributions
    Real Productivity
    Team Work
    @AdamTornhill

    View full-size slide

  35. Diffusion of Responsibility

    View full-size slide

  36. Fractal Value: M. D’Ambros, M. Lanza, and H Gall. Fractal Figures: Visualizing Development Effort for CVS Entities.
    Inter-Team Overlap
    Fractal Value
    0 ~1.0
    Views
    Integration
    Tasks
    Backup
    Tests
    Measure Team Coordination
    Excess Parallel Work
    The Diffusion of Responsibility

    View full-size slide

  37. Measuring Conway’s Law
    Architectural Pattern: Package by Feature
    Views
    Features
    @AdamTornhill
    Front-End Team
    Export Team
    Recommendations Team
    Ads Team
    Calculations Team
    Backup Team

    View full-size slide

  38. Team
    Team
    Team
    Team
    Team
    Team
    Team
    Team
    Team
    Team
    Team
    Team
    The Perils of Feature Teams
    @AdamTornhill

    View full-size slide

  39. Align Your Architecture and your Organisation
    @AdamTornhill

    View full-size slide

  40. Make Decisions Influenced By Data
    @AdamTornhill

    View full-size slide

  41. @AdamTornhill
    Time - The Hidden Dimension of Software Design
    http://www.empear.com/blog/software-revolution-part3/
    The Day I Parsed A Monster
    http://www.empear.com/blog/parse-a-monster/
    Read The Book: Your Code As A Crime Scene
    https://pragprog.com/book/atcrime/your-code-as-a-crime-scene
    Explore The Analyses:
    https://codescene.io/
    [email protected]

    View full-size slide