Big Rewrites Without Big Risks

Incremental development techniques like story splitting are very easy to pick up when your main job is to develop new functionality. You can initially start with the first step in a longer workflow, a simpler UI, tease away nice to have usability aids or drop security controls.

But what do you do when your current project is a rewrite of some portion of the architecture?

Many teams suppose that agile “doesn’t apply in this case”. They start their way at one end of the module and hope to make it still alive at the other end. Throughout, the tests are red. Needless to say, this type of approach increases the technical risk linearly with the duration of the project.

Luckily, there are better ways.

Flavius will talk about what to do when trying to refactor architectures incrementally. He’ll show refactoring patterns and strategies used by teams who changed their codebases and still managed to have a stable build at the end of the sprint.

Audience Learnings

Patterns to use when developers need to rewrite one or more modules. How to do big changes without rendering the code unstable.

Structure

I will present the problem posed by big rewrites when trying to develop incrementally. Then I will offer tips and tricks on how to solve it.

Prerequisites

The participant should have some hands-on experience working on a project where the team needed to rewrite some modules of the solution.