Being effective with legacy projects

Being effective

with legacy projectsKonstantin Kudryashov | @everzet

What are the two hardest problems in

software development?

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

What is a good software design?

A software design is contextual to the people that use and

produce it

A good design is a design that supports

people interacting with it

Any design is a good design in a system that nobody uses or

develops

What are the two hardest problems in software development?

1. Making sure users keep using it

2. Making sure developers keep developing it

Legacy

Technical debt

3 analogies

Restaurant kitchen

Tetris

Broken windows theory

How do we get a legacy problem?

How do we get a legacy problem?

1. Users want the software to change

2. Developers want to change the software

3. Constantly

Legacy is a side-effect of a constant use and

adaptation

In other words...

The system without a legacy problem is the system that is not actively used

Every mature business has a legacy problem

Greenfield does not exist in universes where Excel is invented

1paraphrasing Alberto Brandolini

Taking control of legacy

A technical problem

How do we get a legacy problem?

1. Users want the software to change

2. Developers want to change the software

3. Constantly

People want change

A technical problem

Legacy is a human, not a technology

problem

You don't deal with legacy by rewriting your software

You deal with legacy by rewriting your

collaboration

Deliberate Discovery

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

Step 1Technology Context

Visualise the insight

Step 2Business Context

Get access to analytics and business monitoring tools

People controlling data are the people controlling the

direction of change

Get access to stakeholders

Step 3Constraints

Sit with operators

Analyse customers and their journeys

Research the bug tracker

Step 4Map Risk Areas

Highlight risk areas on the map using discovered

4 Real Data

4 Business Objectives

4 Usage Constraints

4 Technical Constraints

4 Bugs

Step 5Change the way we change the

software

"We must return products back to

stock during refund"

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?

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?

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

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

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

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

Step 6Separate commodity logic from

domain logic

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

Rewrites are rarely effective, because businesses rarely want to change the entire system

A full-system rewrite is an admission of

defeat

We're not stuck with unsustainable codebase

We're stuck with unsustainable approach to it

If we stop running from legacy as if it was a plague...

... and start looking at it as a normal

phase in a system life

Everything that is possible in greenfield becomes possible in

legacy

Behaviour Driven Development

Behaviour Driven Development

in legacy

Being effective

with legacy projects

Delivering outcomes, not software

4 Rate talk: https://joind.in/talk/6b377

4 Join us: http://bit.ly/inviqa-careers

4 Get help: http://bit.ly/inviqa-contact