This document summarizes the experience of a team dealing with legacy code in a critical ordering application. Some of the challenges they faced included a mix of junior and senior developers, preparing for an upgrade, and planning a major design overhaul of legacy code with little documentation. Things that worked well included Scrum processes, bi-weekly releases, automation, and opportunistic refactoring. Areas for improvement included larger design refactors, more testing, and test-driven development. In the future, the author would have liked living documentation, monitoring, and more efficient UI testing. The presentation warns against creating legacy code and encourages design refactoring and better practices.

1. Dealing With Legacy:
The Real-World Experience

2. Why this presentation?
● Share successful practices
● Get suggestions regarding the challenges we
struggled with (that aren't unique to us)
● Provide support for pushing through design
refactorings by revealing the cost of legacy

3. Agenda
1.The Application & Team
2.The Challenges
3.What Worked Well
4.What Could Be Improved
5.What I'd Have Loved To Have
6.Some Other Lessons Learned
7.Legacy Code: Manifestations, why to avoid
● Selected Anti-Patterns
● The Hidden Cost of Legacy

4. The Application & Team
Application: ● Java 1.4, JSP, JSF
● Ordering site critical to ● Ca 8 years, ~2.5k
the business, 1-2k classes, 170 kLOC
orders/day (400 classes and 50
Team: kLOC in the core)
● Team of 5+1, Scrum
● MonsterJsfBean
(improved!): >10k
● WS back-end LOC, 50 constants,
developed by a team 300 properties + 320
abroad methods (½ public)

5. The Challenges
● The whole team exchanged within 1-2 months
● Surprisingly smooth
● Huge difference in expertise levels (seniors x
juniors)
● Preparing migration to an upgraded platform
and a different application server
● Planning of a major design overhaul
● Legacy code* with negligible tech/biz docs
*) See on the next slide

6. What did the code look like?
(More about design refactoring later)

7. What Worked Well
● Scrum / process
● Retrospectives → continual improvement
● Common code review sessions (could be more)
● Pair-programming → learning (c'd be more)
● Timeboxing (meetings, spikes)
● Explicit commitment to each and every task
● Bi-weekly releases → low uncertainty
● CI & deployment package building automation
● Opportunistic (boy scout rule) refactoring

8. What Could Be Improved
● Scrum
● Standup – less reporting, more commitment
● Focused sprints with a clear objective
● Larger-scale refactorings to improve design
● Less defects (how?! more testing?)
● Test-first development and refactoring
● We tried but not always (too much effort) and
the tests weren't always good enough (focus,
coupling)

9. What I'd Have Loved To Have
● “Living documentation” ← Specification by Example
● Up-to-date, clear business logic documentation
● Automated integration/functional testing
● Operational monitoring
● Quick discovery of defects, outages of the
app/dependencies
● Knowledge of performance stats and
bottlenecks
● Feedback on how features are used
● Efficient UI testing (fixtures/deps, jump to

10. Some Other Lessons Learned
● It's crucial to refactor the design as
requirements change to tame complexity
● Tests too coupled to the implementation are
worse than no tests
● A meeting w/o action points with assigned
people and checkpoints is a waste
● Sometimes you must temporarily make code
uglier when refactoring it towards st. better

11. Legacy CODE

12. Selected Anti-Patterns
● Copy & Paste (& Adjust)
● Patch & Go (aka Never Refactor Your Design)
● One Class to Rule Them All
● String Is the Best Data Type (never convert!)
● Singletons & Static Accessors
● ArrayList instead of the highest abstraction
suitable
● => *plication and inconsistent design

13. The Hidden Cost of Legacy
● May be only 10-20% time actually coding
● most time spent figuring out what the code
does & why (partly due to slow UI)
● No specs → what is a feature / bad design /
workaround not needed anymore?
● Prod defects due to
● not understanding hidden dependencies and
varying usage of state variables
● not fixing all the copied & pasted code
fragments

14. Your Action Points :-)
● Don't create legacy code
● Beware the cost of legacy
● Do refactor your design to reflect the business
● Be better
● Consider implementing SbE/Living document.
● Implement operational monitoring
● Make sure your app/UI is easy to test
● Take inspiration from what worked for us
● Retrospectives, Common code reviews, ...

15. THANK YOU!