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

Rescuing legacy software from impending doom (Refactoring from the trenches)

Rescuing legacy software from impending doom (Refactoring from the trenches)

Dealing with an ageing code base is one of the hardest challenges that software development teams face. Legacy code bases can slow teams to a crawl, and therefore it is critical to solve this on the road to agility.
Software rewrites fail at alarming rates! Refactoring - a safer approach - has emerged as the de-facto technique to tackle this challenge.

In this interactive session we will equip attendees with techniques and lessons to help them refactor more effectively. We will share our experience gained while working with various software teams, from start-ups to mid-sized, that attempted to rescue their legacy from impending doom.

Martin Cronjé

August 04, 2015
Tweet

More Decks by Martin Cronjé

Other Decks in Programming

Transcript

  1. RESCUING LEGACY SOFTWARE
    FROM IMPENDING DOOM
    [email protected]
    @martincronje
    [email protected]
    @jacdevos

    View full-size slide

  2. Your participation…

    View full-size slide

  3. Why this talk?

    View full-size slide

  4. Legacy code kills agility

    View full-size slide

  5. Refactoring is hard

    View full-size slide

  6. Refactoring stories
    from the trenches

    View full-size slide

  7. Why, what, when, not how

    View full-size slide

  8. Credits
    • Kent Beck on Small, Safe Steps and TDD
    • Robert C. Martin on Clean Code
    • Martin Fowler on Refactoring Techniques
    • Ward Cunningham on Technical Debt
    • Michael Feathers on Starting with a Mess
    • J.B. Rainsberger relating it to Accidental Complication

    View full-size slide

  9. What is legacy code?
    What is the value in fixing legacy code?
    How do we speak to Product Owners about it?
    Should you rewrite?
    What is refactoring?
    When should we refactor?

    View full-size slide

  10. What is legacy code?

    View full-size slide

  11. Legacy code has a
    negative perception.

    View full-size slide

  12. What is legacy code?

    View full-size slide

  13. • Any code in production
    • Ancient code
    • Unsupported technology
    • Not up to standard
    • Code smells
    You might have said…

    View full-size slide

  14. - Michael Feathers
    code without tests.”
    “legacy code is simply

    View full-size slide

  15. - J.B. Rainsberger
    code that we feel afraid to
    Legacy code is valuable
    change.

    View full-size slide

  16. Summary: Legacy Code?
    Legacy code is risky and expensive to
    change

    View full-size slide

  17. Why fix legacy code?

    View full-size slide

  18. Why fix legacy code?

    View full-size slide

  19. • If it ain't broken, don't fix it
    • Make it easier to work with
    • For our future happiness
    • Good craftsmanship
    You might have said…

    View full-size slide

  20. Professionalism

    View full-size slide

  21. Quality culture

    View full-size slide

  22. Return on investment

    View full-size slide

  23. Increasing the future value

    View full-size slide

  24. In summary
    Improve the code to reduce
    maintenance costs

    View full-size slide

  25. Do POs understand the value
    in fixing legacy code?

    View full-size slide

  26. Do Product Owners understand?
    What do they say?

    View full-size slide

  27. • Not enough time
    • We cannot afford it
    • Business will close-down
    • Just one more feature
    • They allow us to recover
    You might have said…

    View full-size slide

  28. They think refactoring
    fails?

    View full-size slide

  29. They think developers
    play?

    View full-size slide

  30. They don’t understand
    the impact of bad
    design?

    View full-size slide

  31. Do they really say that?

    View full-size slide

  32. How do we explain it to them?

    View full-size slide

  33. Risk to business continuity

    View full-size slide

  34. Unpredictable timelines

    View full-size slide

  35. In summary
    Learn how to communicate the impact
    of legacy code to Product Owners

    View full-size slide

  36. Should we rewrite?

    View full-size slide

  37. Should we rewrite?

    View full-size slide

  38. • No. Rather the devil you know
    • No. It’s too expensive
    • Yes. Use latest technologies
    • Yes. Learnt from mistakes!
    You might have said…

    View full-size slide

  39. Big bang rewrite

    View full-size slide

  40. Lesson #1:
    Unpredictable timelines

    View full-size slide

  41. Lesson #2:
    Puts your business at risk

    View full-size slide

  42. Lesson #3:
    Always harder than you think

    View full-size slide

  43. In summary
    Resist the temptation to rewrite.

    View full-size slide

  44. What is the alternative?

    View full-size slide

  45. Refactoring is a safer bet

    View full-size slide

  46. - Refactoring, Martin Fowler
    and cheaper to modify without
    …make it easier to understand
    behavior.
    changing its observable

    View full-size slide

  47. Increase ease of change, while
    decreasing risk of change

    View full-size slide

  48. Small incremental
    improvements into production

    View full-size slide

  49. Cast safety nets as you progress

    View full-size slide

  50. Start with lowest impact
    improvement

    View full-size slide

  51. In summary
    Improve design without changing
    observable behaviour

    View full-size slide

  52. When do we refactor?

    View full-size slide

  53. Construction Refactoring

    View full-size slide

  54. New code Code changes Solution wide
    TDD Refactoring Litter-Pickup Refactoring
    Comprehension Refactoring
    Preparatory Refactoring
    Planned Refactoring
    Long-Term Refactoring
    Refactoring workflows

    View full-size slide

  55. Cleaning up as we go

    View full-size slide

  56. Shanty Town
    campsite?
    What if this is the

    View full-size slide

  57. problems
    Handling major

    View full-size slide

  58. refactoring
    Tracer bullet

    View full-size slide

  59. In summary
    Clean up as you go, and escalate
    when there is an impending crisis

    View full-size slide

  60. How are you going to make it happen?

    View full-size slide

  61. Code that we’re afraid to change.
    Invest in making change easier and less risky.
    Talk to Product Owners about return on investment.
    Avoid rewrites, favour refactoring.
    Many, small improvements without changing behaviour.
    Keep it clean and escalate when crisis is imminent.

    View full-size slide

  62. COMMUNICATE THE VALUE
    OF IMPROVING THE CODE
    [email protected]
    @martincronje
    [email protected]
    @jacdevos

    View full-size slide

  63. Join us for this course in:
    Oslo, Norway (December)
    London, UK (December)
    Jo’burg, South Africa (October)
    [email protected]
    @martincronje
    [email protected]
    @jacdevos

    View full-size slide

  64. COMMUNICATE THE VALUE
    OF IMPROVING THE CODE
    [email protected]
    @martincronje
    [email protected]
    @jacdevos

    View full-size slide

  65. Reference
    • Beck, Kent (2003). Test-Driven Development by Example, Addison Wesley - Vaseem.
    • Beck, Kent (2001). Extreme Programming Explained: Embrace Change 2nd. ed. Addison-
    Wesley.
    • Fowler, Martin (1999). Refactoring: Improving the design of existing code. Addison Wesley.
    • Feathers, Michael C (2004). Working Effectively with Legacy Code. Prentice Hall.
    • Martin, Robert Cecil (2009). Clean code: a handbook of agile software craftsmanship.
    Upper Saddle River, NJ: Prentice Hall.
    • Cunningham, Ward (2011). Ward Explains Debt Metaphor
    http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
    • Rainsberger, J.B. Fundamental Theorem of Agile Software Development
    https://vimeo.com/79106557

    View full-size slide