We've had this problem with an old codebase. Some things that happened at my company. Note that this was driven by my boss, who is excellent, and not myself.
* Started collecting metrics on code quality. Sonar was setup to do analysis every day. We could see lines of code + test coverage. Its harder to argue against facts.
* Introduced better guidance on what is required for a change (detailed tickets, unit tests) and started enforcing code reviews. This can help reduce the "damage" being caused.
* Started educating management/business sponsors on why code quality is important. Explaining that poor code can/will make business changes more difficult, they were happy for us to dedicate more time on improving. Used the metrics as evidence.
* Hired people who shared his vision. Soon after he joined, he hired others who were dedicated to writing high quality code and keen to refactor the codebase.
* Identified and prioritised the biggest issues. Estimating developer time cost vs business/development value. These required sign off from business sponsors/management.
We still have problems trying to get everyone onboard. Often it can be easy to get everyone to verbally agree to address an issue, but walking the walk is never as easy as talking the talk!
Its been 2/3 years and looking forward there's still a whole mountain to tackle, it seems like we've barely scratched the surface. Looking back, you can see how bad it was and it has actually improved significantly.
We've had this problem with an old codebase. Some things that happened at my company. Note that this was driven by my boss, who is excellent, and not myself.
* Started collecting metrics on code quality. Sonar was setup to do analysis every day. We could see lines of code + test coverage. Its harder to argue against facts. * Introduced better guidance on what is required for a change (detailed tickets, unit tests) and started enforcing code reviews. This can help reduce the "damage" being caused. * Started educating management/business sponsors on why code quality is important. Explaining that poor code can/will make business changes more difficult, they were happy for us to dedicate more time on improving. Used the metrics as evidence. * Hired people who shared his vision. Soon after he joined, he hired others who were dedicated to writing high quality code and keen to refactor the codebase. * Identified and prioritised the biggest issues. Estimating developer time cost vs business/development value. These required sign off from business sponsors/management.
We still have problems trying to get everyone onboard. Often it can be easy to get everyone to verbally agree to address an issue, but walking the walk is never as easy as talking the talk!
Its been 2/3 years and looking forward there's still a whole mountain to tackle, it seems like we've barely scratched the surface. Looking back, you can see how bad it was and it has actually improved significantly.
Good luck!