Being effective with legacy projects

54 %
46 %
Information about Being effective with legacy projects

Published on June 25, 2016

Author: everzet

Source: slideshare.net

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

12. Restaurant kitchen

13. Tetris

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

Add a comment