This document discusses strategies for moving away from legacy code using behavior-driven development (BDD). It summarizes three popular options: 1) Rewriting the entire application from scratch using best practices, 2) Doing technical refactoring of the code, and 3) Taking a business-focused approach using the "BDD pipeline" which involves impact mapping, prioritizing features, example workshops, and BDD layers to support planned changes. The presenter argues that the third option of a BDD pipeline is preferable to a full rewrite or only technical refactoring as it focuses on delivering business value over time rather than rewriting the code.

1. Moving away from
legacy code
with BDD

2. BDD Evangelist
BDD Practice Manager @Inviqa
Creator of Behat, Mink, PhpSpec2,
Prophecy
Contributor to Symfony2, Composer
@everzet

3. This talk is about
• Solving purely technical “TCIAM” problem using
behavioural business analysis and discovery process
• Building a delivery strategy on the idea of the
change appreciation
• Real-life experience

4. This talk is not about
• Greenfield projects
• Maintenance-mode projects
• Solutions for everyone
• How to write code

5. Legacy projects

6. How most developers see
their next project

7. My next
project

8. My next
project
His actual next
project

9. Agile, TDD, BDD,
General QA, etc…
// TODO: refactor this
later

10. Is it really that bad?

11. If the project can afford at least one full-time
specialist on a payroll that whines how horrible
this project is, then surely it did something right.

12. // TODO: refactor this
later

13. // TODO: refactor this
later

14. // TODO: refactor this
later

15. This world is full of brilliant projects that nobody
wants to whine about. Sadly, it’s often simply
because there’s no one left to pay for that.

16. The truth is:
You deliver value!
Just not as effectively as you could

17. • Great value + Awful code = Great product today
• Great value + Great code = Great product tomorrow
• No value + Any kind of code= Awful product anytime

18. • Great value + Awful code = Great product today
• Great value + Great code = Great product tomorrow
• No value + Any kind of code= Awful product anytime

19. // TODO: refactor this
later
Agile, TDD, BDD,
General QA, etc…

20. How?

21. Three popular options
1. Rewrite an entire application using “the right way”
2. Do technical refactoring
3. Do business-oriented rewrite using “BDD pipeline”

22. #1: Full Rewrite

23. #1: Full Rewrite
• Scrum / Kanban
• TDD / BDD / DDD / Other XP goodness
• New everything
• Mirroring functionality

24. #1: Income

25. 6 Months later…

26. #1: Almost there…

27. #1: Full Rewrite
Just spaghetti, please: 4 man years
Full London meal (TDD, BDD, Agile, QA): ??? man years

28. #2: Technical Refactoring

29. #2: Technical Refactoring
• Blackbox testing
• New routing
• New templating system
• Migration of model layer (MySQL -> Mongo)
• Whatever else that is easy to replace

30. #2: Income

31. 6 Months later…

32. #2: Ta-da!!!

33. – Your client. (most likely)
“Exactly what did you do here?”

34. #3: BDD PIPELINE
AKA Business-Focused rewrite

35. Why do legacy
projects suck?

36. Cost
Time
Because of the
cost of change

37. … Of change where?

38. Why do
applications change?

39. Welcome to the
wonderland
of Behaviour Driven Development

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

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

42. 1. Where is this
project going?
Impact Mapping

43. – 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.”

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

46. MVP

47. Product Backlog

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

50. 2. Which features are
going to change?
Business Prioritisation

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

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

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

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

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

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

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

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

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

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

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

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

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

64. Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I 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

65. 4. How to make it work?
Delivery

66. Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I 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

67. Architectural approaches
1. The Inside job
2. The Bridge

68. Architectural approach
#1 The Inside job

69. Step#1: Identify change area

70. Step#1: Identify old logic

71. Step#2: 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?

72. Step#3: 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 upcoming change easier
4. Make scenarios/tests green

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

75. Stories
Examples
Describe
Implement
Design

76. Architectural approach
#2 The bridge

77. Legacy system
Infrastructure
[GET] /products

78. Legacy system
Infrastructure
[GET] /products
[GET] /products/123

79. Legacy system
Infrastructure
[GET] /products
[GET] /products/123
New system

80. Legacy system
Infrastructure
[GET] /products
[GET] /products/123
New system
New system

81. Step#0: Prepare for any change
1. Prepare the application infrastructure for bridging
a. Share sessions
b. Share data
2. Prepare the server infrastructure for bridging

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

83. #3: Income

84. 6 months later…

85. #3: Same ashtrays, better car

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

87. We do that for clients
And coach / train others how to do it
http:// .com

88. Thank you!
@everzet