Generic Strategy for Large Scale Changes to a Legacy Code base - digitalpalireader/digitalpalireader GitHub Wiki

Strategy Name:

Definite Transparent Divide & Conquer (randomly named, can be called anything)
Following is the generic "plan" for coming up with the strategy

Initial investigation

Gathering as much information regarding
- Where we are now (this requires handling the code base for a while)
- The desired future state
Draw a line between current state to desired state punctuated by well defined stages
Super critical is the pin down the definition of

can test independent of stages after
- logical stage is never spread between 2 stages.
ship, derisk / bring out all risk
- even within stage work is all done in master => this is so user testing can happen on staging
is in the direction of goal (minimal throwaway work)
- stage n builds on stage n-1
is worth a stage (should not be too less)
has clear acceptance criteria

transparent: can report progress (like a progress bar)
definite: each stage is heading towards the eventual goal with minimal throwaway work
divide n conquer: breaking down the complexity - in stage n, worry about stage n only!
customers see each stage => feedback on production => unlike any faulty assumption/implementations stay hidden for long
each stage is a good thing to do, independent of next stage
can pause after each stage indefinitely and have someone else resume
can change direction after each stage

Plan will change along the way as new info comes to light but the overall structure of the plan if done right, will hold through out.

DPR Palemoon to DPR Web itself happened this way. But that work is to large & therefore a distraction to the core point being illustrated here.
A smaller example was DPR converted to a PWA mid 2020. Here is how it was planned and executed roughly.
Plan did change along the way but overall strategy remained the same.
The commits were named appropriately so that they can be traced down to the stages.