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.

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...

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

25. Taking control of
legacy

26. A technical problem

27. How do we get a legacy problem?
1. Users want the software to change
2. Developers want to change the software
3. Constantly

28. People want change

29. A technical problem

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

33. Deliberate Discovery

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

35. Step 1
Technology Context

36. Visualise the insight

38. Step 2
Business Context

39. Get access to
analytics and business
monitoring tools

40. People controlling
data are the people
controlling the
direction of change

41. Get access to
stakeholders

43. Step 3
Constraints

44. Sit with operators

45. Analyse customers
and their journeys

46. Research the bug
tracker

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

68. Behaviour Driven
Development

69. Behaviour Driven
Development
in legacy

70. Being effective
with legacy projects

71. Delivering outcomes,
not software

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