Published on June 25, 2016
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
10. Technical debt
11. 3 analogies
12. Restaurant kitchen
14. Broken windows theory
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
18. In other words...
19. The system without a legacy problem is the system that is not actively used
20. Every mature business has a legacy problem
21. Greenfield does not exist in universes where Excel is invented 1 paraphrasing Alberto Brandolini
22. Taking control of legacy
23. A technical problem
24. How do we get a legacy problem? 1. Users want the software to change 2. Developers want to change the software 3. Constantly
25. People want change
26. A technical problem
27. Legacy is a human, not a technology problem
28. You don't deal with legacy by rewriting your software
29. You deal with legacy by rewriting your collaboration
30. Deliberate Discovery
31. 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
32. Step 1 Technology Context
33. Visualise the insight
34. Step 2 Business Context
35. Get access to analytics and business monitoring tools
36. People controlling data are the people controlling the direction of change
37. Get access to stakeholders
38. Step 3 Constraints
39. Sit with operators
40. Analyse customers and their journeys
41. Research the bug tracker
42. Step 4 Map Risk Areas
43. Highlight risk areas on the map using discovered 4 Real Data 4 Business Objectives 4 Usage Constraints 4 Technical Constraints 4 Bugs
44. Step 5 Change the way we change the software
45. "We must return products back to stock during refund"
46. 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?
47. 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?
48. 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
49. 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
50. 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
51. 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
52. Step 6 Separate commodity logic from domain logic
53. 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
54. Rewrites are rarely effective, because businesses rarely want to change the entire system
55. A full-system rewrite is an admission of defeat
56. We're not stuck with unsustainable codebase
57. We're stuck with unsustainable approach to it
58. If we stop running from legacy as if it was a plague...
59. ... and start looking at it as a normal phase in a system life
60. Everything that is possible in greenfield becomes possible in legacy
61. Behaviour Driven Development
62. Behaviour Driven Development in legacy
63. Being effective with legacy projects
64. Delivering outcomes, not software
65. 4 Rate talk: https://joind.in/talk/6b377 4 Join us: http://bit.ly/inviqa-careers 4 Get help: http://bit.ly/inviqa-contact