Misadventures In Legacy CodeEric Lee

Who am I?

Not a professional presenter – be patient!

16 years at Microsoft 6 years in Office building automated

testing systems 9 years in Microsoft Game Studios making

games testable 1 year in Engineering Excellence building

a secure source code portal

Enthusiastic Agile practitioner I’ve inherited at least three “legacy”

systems during my career

The plan

Part 1: What is a legacy system? Part 2: How do I survive a legacy

system? Part 3: How do I avoid creating more

legacy systems?

Part 1: What is a legacy system?

What does legacy mean?

What the dictionary says…leg·a·cy [ léggəssee ]

noun  (plural leg·a·cies)

Definition:

1. bequest made in will: money or property that is left to somebody in a will

2. something from past: something that is handed down or remains from a previous generation or time

Encarta® World English Dictionary

What developers really mean…

Bob Jagendorf

Zombies vs. Legacy apps

Zombies: Legacy apps:

Walking undead corpses Extremely hideous and

disgusting Overwhelm you with

numbers Infect anything they

touch Consume your brain and

destroy your will Very hard to eradicate Campy fiction

Walking undead corpses Extremely hideous and

disgusting Overwhelm you with

numbers Infect anything they

touch Consume your brain and

destroy your will Very hard to eradicate Horrifyingly real

Stuart Halloway says…

“Legacy” is the degree to which code:

fails to capture essence fails to communicate essence captures irrelevant detail (ceremony)

Michael Feathers says…

“Legacy code is code without tests.”

Practical Considerations

Legacy apps are often (but not always) old

Sometimes no original developers remain

Extremely difficult to make changes without breaking things

Critical infrastructure has often been lost

Source code is archaic, bewildering, and way too complex for what it does

Documentation is nonexistent or wrong

No automated test suite

Part 2: How do I survive a legacy system?

"I say we take off and nuke the entire site from orbit. It's the

only way to be sure."

Should we start over?

Sure, if you have unlimited resources Otherwise, probably not! The legacy code base holds valuable,

hard-won knowledge Legacy code base continues to

accumulate new features and bug fixesFeature parity is a moving target

Users want to see regular evidence of progress

Then what do we do?

First, take a deep breath - this is gonna hurt

Take inventory Eliminate friction Build a safety net Divide and conquer Practice software archeology Build for the future Have boat-loads of patience

Take inventory

Understand the environment:History of the projectProblem spaceStakeholdersTarget audienceFuture goals

Capture initial code metrics Inspect and prune all documentation

Eliminate friction

FRICTION

Eliminate friction

Make lists of annoyancesAfter three months problems become

invisible Always ask the five whys Get everything under source control Enable local builds, local execution Repeatable build process

Build scriptsDedicated build machine for official

builds Repeatable deployment

Build a safety net

You need tests!Automated if you can, manual if you

can’tLet you change the code with less terror

Baby stepsStart with integration testsDon’t try to write unit tests for

everything all at once Michael Feathers, Working Effectively

With Legacy Code

Divide and conquer

Don’t start with sweeping architectural changes

Focus on one small area at a time Refactor/rewrite as you go Build firewalls to protect new code

from old code Practice the Boy Scout rule Have patience and a long-term plan

Software archeology

Software archeology

Legacy code is like an archeological dig siteLayer upon layer of historyLots of rubble from previous times

Before changing code, try to understand:The historical purpose of the codeThe desired purpose of the code today

Be suspicious and paranoidAny mysterious behavior will bite you

laterAlways look for root causes

Break the cycle

Clear away the rubble Source code is a liability, not an

assetDelete dead codeDelete redundant commentsSimplify, simplify, simplify!I reduced one component from 4000 to

400 ELOC, another from 6800 to 3200 Write unit tests for all new code

Break the cycle

Focus on today’s requirements, not ancient history

Rethink all assumptions Bad code is often a symptom of

squishy problem definition Get really crisp on the fundamental

concepts

Forensic development

The code lies, don’t trust it Dig until you understand the whole

story Collect evidence and build a case Refactor the code until it tells the

truth

How do I avoid creating more legacy systems?

Do the right thing!

“Always code as if the person who ends up maintaining your code is a violent psychopath who knows

where you live.”

The right code

Write unit and integration tests for all code

Follow S.O.L.I.D design principles Be a naming Nazi Refactor constantly to match current

goals Avoid “minimally invasive” fixes Write self-explanatory code, skip

heavy docs

The right process

Promote shared ownership Create and maintain long-term vision Stay focused on business value Automate everything Stamp out friction Limit technical debt

Questions and followup

Any questions? Contact me!

Email: saintgimp@hotmail.comTwitter: @saintgimpBlog: http://blogs.msdn.com/elee