Cleaning Code - Tools and Techniques for Large Legacy Projects
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Cleaning Code - Tools and Techniques for Large Legacy Projects



A presentation I gave at the 2013 ACCU conference

A presentation I gave at the 2013 ACCU conference



Total Views
Views on SlideShare
Embed Views



14 Embeds 1,943 1898 15 9 6 3 2 2 2 1 1 1 1 1 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

Cleaning Code - Tools and Techniques for Large Legacy Projects Presentation Transcript

  • 1. CleaningcodeTechniques forLarge Legacy Restoration Projects~~---~~Mike Long
  • 2. What’s in this for you?• Gain an understanding of the value of legacy• Learn how to make the business case forremedial work in large software projects• Know the tools necessary to be able toquantify and visualize technical debt in bigprojects• How to manage large legacy restorationprojects
  • 3. Legacy
  • 4. Code I have knownMini-Legacy
  • 5. Code I have knownGreenfield Heaven
  • 6. Code I have knownLegacysaltmines
  • 7. COBOLRubeGoldberg~ or ~What is aLegacyRestorationProject?
  • 8. What is a Legacy restoration project?“A legacy system is an old method, technology,computer system, or application program.”Wikipedia
  • 9. What is a Legacy restoration project?“To me, legacy code is simply code withouttests”Michael Feathers
  • 10. What is a Legacy restoration project?“Some crap made by someone else”Developers, Developers, Developers
  • 11. Large: Software at scale is a differentbeast• > 1MLoC• > 10 years old• > 100 developers• => Large Legacy Project
  • 12. What is a Legacy restoration project?• Business commitment• Large, long lived codebase• Valuable codebase• Step change in quality• Specific targets• Time-limited
  • 13. How does a codebase become a bigmess?• Explosive growth – big bang development• Sustained schedule pressure• No quality requirements• High staff turnover• Success
  • 14. How Why does a codebase become abig mess?• Feature driven development plans• Stakeholders don’t know software• Developers don’t know software• Quality is tested-in, not built-in• Under-empowered technical leaders
  • 15. What to do when things get bad
  • 16. “organizations which design systems … areconstrained to produce designs which arecopies of the communication structures ofthese organizations.”
  • 17. “This point of view has producedthe observation that theres neverenough time to do something right,but theres always enough time todo it over”
  • 18. Rewrite trap #1: re-implementingexisting features == commercialsuicide• Netscape• Borland• Microsoft
  • 19. Rewrite trap #2: The 2nd System Effect“This second is the mostdangerous system a man everdesigns…The result, as Ovidsays, is a “big pile.”
  • 20. Too big to fail?
  • 21. Should we declare bankruptcy?For a re-write to be worth it:• We really have “enough time to do it over”– Money is no object, re-implementation of existing features• We use incremental value delivery to stave off the secondsystems effect– mature and disciplined team• We can mitigate the knowledge loss– small and simple system, and the same team as initialimplementation• And the existing platform is facing obsolescenceFor all other cases, rewrite is commercial suicide
  • 22. Tools and techniques
  • 23. Identify & remove waste
  • 24. The Carrying Cost of Code
  • 25. Carrying Costs• Large projects take time to build• Defect tracking systems• Communication costs• Knowledge costs
  • 26. How much of your code is dead?• Callcatcher• Listen to your linker– [Obsolete]– __declspec(deprecated(“**TESTING DEAD**”))
  • 27. Duplicate code
  • 28. Tests are inventory• Tests are inventory, whether scripts, unit tests,or gui tests• Long term failing tests– Delete them or fix them,– then automate this process• Flicker tests
  • 29. There are no fixed costs• Exploit the huge opportunities for wastereduction in large legacy– If you have a big development population, anywaste reduction is a huge boost to productivity– Think build times, feedback delays, broken builds,testing cycles, installation times• But baseline and monitor it!• Measure it in business terms ($$$)
  • 30. Sharp tools• Look for waste introducing systems– Legacy Version control systems– Legacy Defect tracking• Introduce productivity enhancing tools– Continuous Integration– Automation
  • 31. Automate the donkey work• Builds• Dev Setup• Deployment• Testing• Support
  • 32. Churn• What is changing?• What is not changing?– The active set of classes• Drive your decisions on where to put youreffort
  • 33. Static Analysis• The compiler is the first port of call– -wall or /warn:4• I have had very good experiences withcoverity and cppcheck, YMMV• Resource leak detection and memorycorruption detection
  • 34. Visualization
  • 35. Visualization
  • 36. What can you visualize with this?• Complexity• Defects• Static analysis results• Churn• Understanding• Maintainability
  • 37. “Up and to the right”• Trends are important• Only trend metrics thatwill change (no-one ismotivated by codecoverage going from2.066 to 2.067%)• Put the goal or nextmilestone in the trend• Treemaps can also showtrends
  • 38. Making the business case
  • 39. “We need to fix this” *Citation Needed+
  • 40. Quantify, visualize, communicate• Quantify:– Communicate in terms of measured business costsand business benefits• Visualize:– A picture is worth a thousand bug reports• Communicate:– blah, blah, consultant, blah
  • 41. Metrics• Hard:– Complexity– coverage– test cases– churn, turmoil,changeset frequency– static analysis, deadcode, duplicate code,warnings,– Defects (escaped)• Soft:– Feature implementationtime– Customer satisfaction– Employee satisfaction
  • 42. Avoiding metricide
  • 43. Hard conversations• “We’re going slow now, but to go faster weneed to slow down”• “As we improve the codebase we willintroduce regressions in seemingly randomways”• “Throwing money at the problem is not goingto significantly move the needle on quality”
  • 44. How much effort to spend on Quality?• Hint: you don’t get to decide• You are going to have to sacrifice featuredevelopment• in exchange you must promise more frequentrelease quality increments
  • 45. Managing Legacy Restoration
  • 46. Legacy Restoration is CultureChange• Change can’t happen without new values• New values must be driven by new culture• Identifying waste requires new perspective• From Complaining to Fixing
  • 47. Phases to change1. Establish a sense of urgency2. Create a guiding coalition3. Develop a vision for thechange4. Communicate the vision forbuy-in5. Empower broad-based action6. Generate short-term wins7. Never let up8. Incorporate changes into theculture
  • 48. Quality by Being Careful• Defects come from incomplete communication,not only mistakes• The need for carefulness is fear in disguise• Fear of changing code leads to localized bug fixesWrite clean and understandable codePeer reviewDifferent levels of specification and testing
  • 49. Improve both trust and quality• Without trust you can’t– get the sponsorship to invest in internal quality– have the developers believe in a better future• Trust comes with transparency
  • 50. Lottery Factor
  • 51. Not my stuff• Large long-lived codebases rarely have manyof the original developers around• This makes the current developers codearcheologists• Ownership comes before collective ownership• Engineers are historians
  • 52. Engineers as historians• The larger a codebase is, the more of it will becompletely unknown to the development team,especially if the project went through a period ofexplosive growth.• Developers are more likely to re-implementfunctionality that already exists• There will be a lot of cargo cult programming. Existingpatterns in the codebase will be copied withoutknowing the true reasons behind doing so. This isdangerous because even the bad practices and leakyabstractions will be followed and cemented
  • 53. Knowledge and Skills• Knowledge sharing• Lottery factor• Skills matrix• Code understanding• Pair programming• Code reviews• Learning culture
  • 54. Where to start: churn + roadmap• Combine what is changing with your newdevelopment roadmap– Things that don’t change:• don’t have bugs• are not slowing down feature development• are probably rarely read– Compare new feature only development withrefactoring + new development• improving areas of high churn will h
  • 55. Is it really worth it?• In making the case for remedial work, youneed to justify the cost – it might really becheaper for the company to have crappy code.• If this is the case, you might want to lookelsewhere for work. There are no happyendings here• The good news is that this situation is highlyunlikely
  • 56. Resources
  • 57. Change should be managed• Direction– Look for the bright spots,think in terms of specificbehaviors, be specific ingoals• Motivation– Make people feel the needfor change, make it small,cultivate a growth mindset• Environment– Change the situation, buildhabits, and rally the herd
  • 58. • How to get legacy codeunder automated test• How to breakdependencies• Strategies for dealingwith common anti-patterns
  • 59. • Detailed explanations of70 refactorings togetherwith the mechanics ofhow to apply themsafely
  • 60. • A structured techniquefor avoiding the weedswhen performing deeprefactoring
  • 61. 1LibreOffice: the story ofcleaning and re-factoringa giant code-baseMichael Meeks <>mmeeks,#libreoffice-dev,“Stand at the crossroads and look; ask for theancient paths, ask where the good way is, and walkin it, and you will find rest for your souls...” -Jeremiah 6:16
  • 62. Conclusions
  • 63. Conclusions• Prevention is better than cure• Legacy software is valuable software• There is always a business case for restoration– You just need to prove it• Restoration is culture change
  • 64. Too big to fail?
  • 65. Questions?