Greenfield projects are awesome – you can develop highest quality application using best practices on the market. But what if your bread actually is Legacy projects? Does it mean that you need to descend into darkness of QA absence? Does it mean that you can’t use Agile or modern communication practices like BDD? This talk will show you how to be successful even with the oldest legacy projects out there through the usage of Agile processes and tools like Impact Mapping, Feature Mapping, Example Workshop, Story and Spec BDDs.

1. Moving away from
legacy code
with BDD

2. BDD Practice Manager
Creator of Behat - Cucumber
for PHP
Software Engineer turned
Stakeholder whisperer
Konstantin
Kudryashov
@everzet

3. This talk is about
• Solving purely technical “TCIAM” problem using
behaviour driven development practices and agile
discovery processes
• Planning a delivery strategy on the basis of change
appreciation
• Real-life experience

4. Legacy projects

5. How most teams see their
next project

6. our next
project

7. our next
project
their actual next
project

8. Agile, TDD, BDD, etc… // TODO: refactor later

9. Is it really that bad?

10. If a project can afford a salary of an engineer
concerned about the project state,
then the project state is not that bad.

11. // TODO: refactor later

12. // TODO: refactor later

13. // TODO: refactor later

14. This world is full of brilliant projects that nobody
is concerned about. Sadly, it’s often because
there’s no one left to care.

15. You deliver value
Just not as effectively as you could

16. Great value + Awful code = Great product yesterday

17. Great value + Awful code = Great product yesterday
Great value + Great code = Great product tomorrow

18. Great value + Awful code = Great product yesterday
Great value + Great code = Great product tomorrow
No value + Any code = Awful product anytime

19. Great value + Awful code = Great product yesterday
No value + Any code = Awful product anytime

20. Great value + Awful code = Great product yesterday
Great value + Great code = Great product tomorrow

21. // TODO: refactor laterAgile, TDD, BDD, etc…

22. Rewrite
all the things!

24. learning

25. learning
trash bin
else

26. learning • Agile
• XP
• BDD
trash bin
else

27. learning • Agile
• XP
• BDD
trash bin
else

28. learning • Agile
• XP
• BDD
trash bin
else

29. Working system

30. 1 year later…

31. nearly working system

32. how come?

33. learning • Agile
• XP
• BDD
trash bin
else

34. learning • Agile
• XP
• BDD
trash bin
else

35. legacylegacy

36. legacylegacy

37. shiny new
legacylegacy

38. shiny new
£A
legacylegacy

39. U
my
features!!!
shiny new
£A
legacylegacy

40. shiny new
£A
U
my
features!!!
legacylegacy

41. shiny new
£A + £B
U
my
features!!!
legacylegacy

42. shiny new
£ U
my
features!!!
£A + £B
my
opportunities!!!
legacylegacy

43. shiny new
£ U
my
features!!!
£10,000/m
£A + £B
my
opportunities!!!
legacylegacy

44. shiny new
£ U
my
features!!!
£10,000/m £10,000*x
£A + £B
my
opportunities!!!
legacylegacy

45. shiny new
£ U
my
features!!!
£A + £B
my
opportunities!!!
legacylegacy

46. £A + £B
£ U
my
features!!!
shiny new
my
opportunities!!!
legacylegacy

47. shiny new
£A + £B + £C
my
opportunities!!!
£ U
my
features!!!
legacylegacy

48. my
opportunities!!!
£
shiny new
£A + £B + £C*?
my
opportunities!!!
£ U
my
features!!!
legacylegacy
my
opportunities!!!
£
my
opportunities!!!
£

49. it does not work!
Well, not always...

50. Why do legacy
projects suck?

51. Cost
Time
cost of change

52. How do we balance
the cost of change?

53. Cost
Time
cost of ownership

54. Cost
Time
cost of ownership

55. Cost
Time
cost of change
cost of ownership

56. Cost
Time
rewrite

57. take ownership only when
you need to support change

58. … Of change where?

59. Innovation Predictability

60. Innovation Predictability

61. Innovation Predictability
Constant change,
never ideal
Rarest change,
good is good enough

62. Questionnaire
1. Where is this product going?
2. Which features need to change?
3. How are they going to change?
4. How to support that change?

63. “BDD Pipeline”
1. Where is this product going?
2. Which features need to change?
3. How are they going to change?
4. How to support that change?
• Impact Mapping
• Value Prioritisation
• Example (3 Amigos) Workshop
• BDD layers

64. 1. Where is this
product going?
Impact Mapping

65. – Gojko Adzic
“Impact mapping is a strategic planning technique
that prevents organisations from getting lost
while building products and delivering projects,
by clearly communicating assumptions, helping
teams align their activities with overall business
objectives and make better roadmap decisions.”

66. Four levels of Impact Map
1. Why? are we doing all this (rewrite)? What is the
goal we’re trying to achieve?
2. Who? will be impacted by it?
3. How? can they help us to achieve the goal?
4. What? can we do to support them?

68. MVP

69. Product Backlog

71. In order to buy more products
As a customer
I need to have a product autocompletion in the search field

72. 2. Which features are
going to change?
Value Prioritisation

73. In order to maintain my shopping history
As a site visitor
I need to be able to register on this site

74. In order to maintain my shopping history
As a site visitor
I need to be able to register on this site
benefit
actor

75. SELECT s.*
FROM backlog as s
ORDER BY s.role, s.benefit
LIMIT 25

76. 3. How are these features
going to change?
Example (3 Amigos) workshops

77. Three layers of a User-Story
• Business rule(s)
• Communication
• Acceptance criteria

78. Three layers of a User-Story
• Business rule(s)
• Communication in Examples
• Acceptance criteria

79. In order to keep track of stock
As a store owner
I want to add items back to stock when they are returned
Feature: Returned items go back to stock

80. Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

81. Scenario: Replaced items should be returned to stock
Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

82. Scenario: ...
Scenario: Replaced items should be returned to stock
Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

83. Scenario: ...
Scenario: ...
Scenario: ...
Scenario: ...
Scenario: ...
Scenario: Replaced items should be returned to stock
Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

84. Given a customer previously bought a black sweater from us
And we currently have three black sweaters left in stock
When customer returns the sweater for a refund
Then we should have four black sweaters in stock
Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

85. 4. How to support
that change?

86. Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock
Given a customer previously bought a black sweater costing 15$ from us
And we currently have three black sweaters left in stock
When customer returns the sweater for a refund
Then we should have four black sweaters in stock
And customer account should be debited with 15$

87. Step#1: Identify change area

88. Step#2: Identify old logic

89. Step#3: Discuss old logic
1. What should 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?

90. Scenario: Replaced items should be returned to stock
Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

91. Scenario: Cost of refunded item should be returned to customer bank account
Scenario: Cost of refunded item should be returned to customer PayPal account
Scenario: Cost of refunded item should be returned to customer via in-shop credits
Scenario: Replaced items should be returned to stock
Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

92. @legacy
Scenario: Cost of refunded item should be returned to customer bank account
@legacy
Scenario: Cost of refunded item should be returned to customer PayPal account
@legacy
Scenario: Cost of refunded item should be returned to customer via in-shop credits
Scenario: Replaced items should be returned to stock
Scenario: Refunded items should be returned 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
Feature: Returned items go back to stock

93. Step#4: Prepare for A change
1. Cover old behaviour in an end-to-end fashion
2. Make sure that scenarios/tests are green
3. Refactor code to make the lower testing possible
4. Convert scenarios/tests to lower level tests

94. Step#5: Make a change
1. Automate new scenarios
2. Make scenarios green by applying BDD loops

95. Stories
Examples
Describe
Implement
Design

96. Working system

97. 1 year later…

98. Same ashtrays, better system

99. Stop dreaming of a greater code
Find a way to deliver a greater value

100. We do that for clients
And help others to do it
http:// .com

101. Thank you!
@everzet