I see, but sometimes the process is a bit different for example, in large projects with the old codebase and bad architecture, the most difficult part is to start a conversation with the customer that the codebase needs to be reworked, and if you do so you open harrowing conversation about the timeline, budget, scope that needs to be del…
I see, but sometimes the process is a bit different for example, in large projects with the old codebase and bad architecture, the most difficult part is to start a conversation with the customer that the codebase needs to be reworked, and if you do so you open harrowing conversation about the timeline, budget, scope that needs to be delivered in and all bunch of things that are not only code related ( which I guess you have not mentioned in the post :) ). It depends on the project if there are many people involved, I think the refactoring should start on the management/process level so all sides have a roadmap and agree on what and when needs to be done.
I see, but sometimes the process is a bit different for example, in large projects with the old codebase and bad architecture, the most difficult part is to start a conversation with the customer that the codebase needs to be reworked, and if you do so you open harrowing conversation about the timeline, budget, scope that needs to be delivered in and all bunch of things that are not only code related ( which I guess you have not mentioned in the post :) ). It depends on the project if there are many people involved, I think the refactoring should start on the management/process level so all sides have a roadmap and agree on what and when needs to be done.
Yes of course; the alignment should be the first, I thought you asked on the technical side. This is a big story how to do it then.