Being effective with legacy projects
5 likes1,312 views
The document discusses the challenges and strategies of managing legacy software projects, emphasizing that legacy issues arise from ongoing user and developer demands for change. It outlines a six-step approach to effectively deal with legacy, focusing on technology and business contexts, constraints, risk mapping, and changing development approaches. The key takeaway is that legacy is a human problem rather than a technical one, and addressing it requires collaborative efforts rather than complete rewrites of software systems.
Being effective with legacy projects
- 1. Being effective with legacy projects Konstantin Kudryashov | @everzet
- 2. What are the two hardest problems in software development?
- 3. What are the two hardest problems in software development? 1. Order of arguments in string and array functions 2. Which line do you put an opening bracket on
- 4. What is a good software design?
- 5. A software design is contextual to the people that use and produce it
- 6. A good design is a design that supports people interacting with it
- 7. Any design is a good design in a system that nobody uses or develops
- 8. What are the two hardest problems in software development? 1. Making sure users keep using it 2. Making sure developers keep developing it
- 9. Legacy
- 10. Technical debt
- 11. 3 analogies
- 13. Tetris
- 15. How do we get a legacy problem?
- 16. How do we get a legacy problem? 1. Users want the software to change 2. Developers want to change the software 3. Constantly
- 17. Legacy is a side-effect of a constant use and adaptation
- 22. The system without a legacy problem is the system that is not actively used
- 23. Every mature business has a legacy problem
- 24. Greenfield does not exist in universes where Excel is invented 1 paraphrasing Alberto Brandolini
- 27. How do we get a legacy problem? 1. Users want the software to change 2. Developers want to change the software 3. Constantly
- 30. Legacy is a human, not a technology problem
- 31. You don't deal with legacy by rewriting your software
- 32. You deal with legacy by rewriting your collaboration
- 34. Dealing with legacy in 6 steps 1. Technology Context 2. Business Context 3. Constraints 4. Risk Areas 5. Changing the way we change the software 6. Separating commodity logic from domain logic
- 39. Get access to analytics and business monitoring tools
- 40. People controlling data are the people controlling the direction of change
- 45. Analyse customers and their journeys
- 47. Step 4 Map Risk Areas
- 48. Highlight risk areas on the map using discovered 4 Real Data 4 Business Objectives 4 Usage Constraints 4 Technical Constraints 4 Bugs
- 49. Step 5 Change the way we change the software
- 50. "We must return products back to stock during refund"
- 51. 5.1: Categorise the change 1. Is it a mission-critical change? 2. Is it a change in a mission-critical area? 3. Will this change affect any area of risk?
- 52. 5.2: Discover the current behaviour 1. What does this thing do? 2. What if it suddenly stops doing it? 3. How would you know if it doesn't work? 4. How would you know if it does?
- 53. Feature: Returned items go back to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Scenario: Refunded items are returned to stock Scenario: Replaced items are not returned to stock
- 54. Feature: Returned items go back to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Scenario: Refunded items are returned to stock Scenario: Replaced items are not returned to stock @legacy Scenario: Item refunded with in-shop credits @legacy Scenario: Item refunded to bank account @legacy Scenario: Item refunded to PayPal account
- 55. 5.3: Protect the current behaviour 1. Cover @legacy behaviour in an end-to-end fashion 2. Make sure that scenarios are green 3. Refactor code to make isolated system- testing possible 4. Convert scenarios to isolated system- tests 5. Remove @legacy tag
- 56. 5.4: Make the change 1. Automate the new scenarios as isolated system-tests 2. Push the logic down to the unit level with unit-tests 3. Make unit-tests green 4. Make scenarios green
- 58. Step 6 Separate commodity logic from domain logic
- 59. Separate commodity logic from domain logic 4 Not every sub-system needs to change 4 Different sub-systems will change at different cadence 4 The more aligned our changes are to our objectives, the smaller they would be
- 60. Rewrites are rarely effective, because businesses rarely want to change the entire system
- 61. A full-system rewrite is an admission of defeat
- 62. We're not stuck with unsustainable codebase
- 63. We're stuck with unsustainable approach to it
- 64. If we stop running from legacy as if it was a plague...
- 65. ... and start looking at it as a normal phase in a system life
- 66. Everything that is possible in greenfield becomes possible in legacy
- 70. Being effective with legacy projects
- 72. 4 Rate talk: https://joind.in/talk/6b377 4 Join us: http://bit.ly/inviqa-careers 4 Get help: http://bit.ly/inviqa-contact