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.

Transcript

1. RESCUING LEGACY SOFTWARE FROM IMPENDING DOOM martin@nreality.com @martincronje jacques@nreality.com @jacdevos
2. martin@nreality.com @martincronje
3. jacques@nreality.com @jacdevos
4. Your participation…
5. Why this talk?
6. Legacy code kills agility
7. Refactoring is hard
8. Refactoring stories from the trenches
9. Why, what, when, not how
10. 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
11. 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?
12. What is legacy code?
13. Legacy code has a negative perception.
14. What is legacy code?
15. • Any code in production • Ancient code • Unsupported technology • Not up to standard • Code smells You might have said…
16. - Michael Feathers code without tests.” “legacy code is simply
17. - J.B. Rainsberger code that we feel afraid to Legacy code is valuable change.
18. Summary: Legacy Code? Legacy code is risky and expensive to change
19. Why fix legacy code?
20. Why fix legacy code?
21. • 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…
22. Professionalism
23. Quality culture
24. Return on investment
25. Increasing the future value
26. In summary Improve the code to reduce maintenance costs
27. Do POs understand the value in fixing legacy code?
28. Do Product Owners understand? What do they say?
29. • Not enough time • We cannot afford it • Business will close-down • Just one more feature • They allow us to recover You might have said…
30. They think refactoring fails?
31. They think developers play?
32. They don’t understand the impact of bad design?
33. Do they really say that?
34. How do we explain it to them?
35. Risk to business continuity
36. Unpredictable timelines
37. In summary Learn how to communicate the impact of legacy code to Product Owners
38. Should we rewrite?
39. Should we rewrite?
40. • No. Rather the devil you know • No. It’s too expensive • Yes. Use latest technologies • Yes. Learnt from mistakes! You might have said…
41. Big bang rewrite
42. Lesson #1: Unpredictable timelines
43. Lesson #2: Puts your business at risk
44. Lesson #3: Always harder than you think
45. In summary Resist the temptation to rewrite.
46. What is the alternative?
47. Refactoring is a safer bet
48. - Refactoring, Martin Fowler and cheaper to modify without …make it easier to understand behavior. changing its observable
49. Increase ease of change, while decreasing risk of change
50. Small incremental improvements into production
51. Cast safety nets as you progress
52. Start with lowest impact improvement
53. In summary Improve design without changing observable behaviour
54. When do we refactor?
55. Construction Refactoring
56. New code Code changes Solution wide TDD Refactoring Litter-Pickup Refactoring Comprehension Refactoring Preparatory Refactoring Planned Refactoring Long-Term Refactoring Refactoring workflows
57. Cleaning up as we go
58. Shanty Town campsite? What if this is the
59. problems Handling major
60. refactoring Tracer bullet
61. In summary Clean up as you go, and escalate when there is an impending crisis
62. How are you going to make it happen?
63. 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.
64. COMMUNICATE THE VALUE OF IMPROVING THE CODE martin@nreality.com @martincronje jacques@nreality.com @jacdevos
65. Join us for this course in: Oslo, Norway (December) London, UK (December) Jo’burg, South Africa (October) martin@nreality.com @martincronje jacques@nreality.com @jacdevos
66. COMMUNICATE THE VALUE OF IMPROVING THE CODE martin@nreality.com @martincronje jacques@nreality.com @jacdevos
67. martin@nreality.com @martincronje jacques@nreality.com @jacdevos
68. 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