So you have a working piece of software but you know the quality needs to improve. The team might be saying alarming things like “we need to rewrite this entirely.” Should you halt feature development for weeks or months? Probably not.
Keep Producing Features
Features are what makes your product attractive to your customers. It’s why they choose your product in the first place. And hopefully, it’s why they’re paying you as well.
So stopping the development of new and requested features isn’t a decision taken lightly. Some companies have done so, and successfully.
A notable example is how Microsoft more or less stopped all development on Windows in 2002, when it launched its Trustworthy Computing Initiative. Windows was notoriously insecure, being plagued by malware attacks. Microsoft made a major investment in its engineers and in fixing many vulnerabilities. If you used Windows before the Initiative and still do so today, you can see that it had an important and lasting effect on the reliability and security of Windows.
But chances are you don’t have the resources to risk such an undertaking. So it’s crucial that you still produce new features and modify existing ones.
Continuous Small Investments
It’s also crucial to improve the quality of your code, without changing any of it’s behavior. This is what refactoring is all about: improving quality so that future changes will cost less.
Doing this all at once is risky and will cost you. It’s better to plan small slots of time for improvements and to plan these continuously.
I haven’t read the book myself, but “A Philosophy of Software Design” by John Ousterhout proposes this:
I suggest spending about 10 – 20 % of your total development time on investments. This amount is small enough that it won’t impact your schedules significantly, but large enough to produce significant benefits over time.
John Ousterhout – A Philosophy of Software Design
I think this is a good place to start. If you’re working in iterations, it’s easy to plan in a few days or hours where specific problems with the code can be addressed.
Involve the team in identifying and prioritizing issues. Break down larger tasks into smaller ones, so that the work fits in the agreed time frame. Be sure everyone agrees on the improvement and then let them do the work. Both the developers and the company will benefit.
Even if they would rather rewrite entire pieces of software, doing it bit by bit ensures that customers still see new features and that developers see that there is improvement. In time, their development speed should increase, reliability should improve and morale will do so too.