A poor codebase doesn't prohibit a team from making incremental improvements over time, but it's important that clients understand that doing so is usually the most inefficient way to go about doing things. The longer you leave the bad foundation in, the more complicated things get as updates are compounded.
It's like remodeling the bathroom. You could pull down the sheetrock, update the plumbing, then put it all back. Then come back later and pull down the sheetrock, update the electrical, then put it all back. Only to realize the floor joists are sagging and now the wall needs to be reframed.
I think you know that already, but it's worth repeating.
So, what does that leave you? Well, after communicating this to the client, I'd make a really long laundry list of things that could be improved. For each one, decide on how big of a benefit it is to the user/business and decide how much effort/money it will take. You'll end up with a matrix like this:
Easy to implement Hard to implement
|
|
Greatly |
Improves UX |
|
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
|
Somewhat |
Improves UX |
Everything that gets plotted into the upper left quadrant is the first round of work. This is the 'most bang for your buck' list of things to do.
After than, the lower left and upper right items can be analyzed to see if they warrant the effort at this time. Anything in the lower right is likely best left for if/when the system gets rewritten.
Footnote: There's other ways to plot the tasks, too. Another variation that adds a 3rd 'axis' is:
Easy to implement Hard to implement
|
|
$ |
|
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
|
$$$$$ |
And then use a different indicator for how much of a benefit it is to the user (size or color of plot points).
