Talk by Dave Thomas.
Slides TBA. Video link TBA.
Intro
How to take an old code base that is still producing $$$ for a company despite all the terrible things in it
(poor structure, technical debt, black box, etc)
Agile teams accumulate technical debt by moving fast!
The Legacy Evolution Proposition
A business will want to replace a legacy application for the following reasons:
- Lack of documentation
- Lack of tests
- Lack of knowledge of code base
- Older language/platform
Difficulties
- Systemic change is really hard and is usually never finished
- Monetizing, training and retaining teams is hard
- Excitement for a new project eventually turns to exhaustion
Typical Code-Driven Approach
- Rewrite it all
- Outsource it
- Agile and TDD it!
- Just make it all cloud microservices
Refactoring is a joke bcause the surface area is too big. There are no tests so can’t tell if your refactor is safe.
Avoid big bang systemic changes - they tend to have very minimal impact (maybe 10%).
Target Value-Driven Development
- ID the simplest changes that can possibly work and deliver an ROI.
- Choose projects which can be narrowly scoped to:
- Selective code
- Data-flow focus
- Selective code
- Put a small team of key skills on a specific tactical target.
- Timebox the changes to 3-4 months.
- MUST have measurable values and SLAs.
Leverage Innovations
By order of most -> least effective:
- Improved business practices: easiest way (no need for code!)
- Improve hardware technology: performance, capacity, scalability. It gives you very quick leverage (and is cheaper than paying devs!)
Hardware always saves lousy software. You want your app to go faster? Wait 10 years for hardware to get better, you get a 1000x improvement!
- Improve Software Technology: algorithm, language database, cloud, machine learning, etc
- Improve Software Practices - property based testing, immutability, programming models
Set property based testing as a 1st class citizen (forget unit tests)
Management buy in ROI + Risk
Business needs to provide:
- Clear, tangible, measurable goals.
- ROI model shows significant business value (5x > 15%).
- Implementation of timeline of 3-5 months.
- Minimal impact on day-to-day business operations.
- Strong senior business sponsor.
Technical requirements:
- Small team with a track record.
- Access to specialized skills and talents (won’t be learned on the job - needs expert training).
- Localized changes - minimal dependencies.
- An SLA that is easy to monitor by acceptance tests.
- POC validation in weeks.
- Proof of Sale validation in weeks.
- Straight forward DevOps deployment.
- Independent acceptance testing.
Optimal Places to Look for Improvements
- Small computation bottle necks.
- Highly structured rules / calculations.
- Points of high variability / constant change.
The Lean Data + Flow Approach
Why Focus on Data + Flow?
- Data is Hard to Change (persists).
- Data is the largest and most stable corporate asset.
Data + Flow focused insertion points:
- DB, file, log, messaging, serialization.
- Shared memory, disk, network.
- Functional transformers, ETL interface, map reduce, GPU
- Synchronous replication (ie. all data is in Mongo, blobs are then replicated to another DB)
Legacy Innovation Patterns
- Table/Data driven to accommodate variability (
code => tables | rules|constraints...) - Make it look like the web (
integration => http/atom/rest vs apis) - You really only need 1 API (make it look like a
SELECT) - Leverage massive memory (RAM, NVME)
- Simpler code executes @ speed.
- Reduce cache complexity using in memory databases.
- Simpler code executes @ speed.
- Simple streaming / data flow
- Natural isolation, loose, one-way coupling
- Natural isolation, loose, one-way coupling
- Leverage immutable data - RDB + BDB, logs
- Reduce complexity of updates.
- Leverage replicated subsets.
- Reduce complexity of updates.
- Make use of batching (threads are a bad idea).
Refactoring a DB is hard. Moving tons of data using an API is very expensive (logs are a common approach). For example, instead of migrating, move the disk or move data in a batch.
- Go beyond TDD - Property-Based Testing
- Apply an independent implementation of validations.
- Apply an independent implementation of validations.
Summary
It’s fun working with legacy applications because they provide so many opportunities for improvement and creativity. However, it is crucial that you do this with data to validate if a project is successful or not.