We have "priority" and "severity" fields in our bug tracking system. We define severity as "how it impacts the user" and priority as "how it impacts the product".
My question is about how to categorize a "code improvement" task in severity and priority. Suppose the improvement does not change any behavior but makes it a "better code". We anticipate a long term maintenance improvement overall but it's hard to quantify.
When we use our definitions for priority and severity, a code improvement gets the lowest values for both unless you introduce some hard to predict long term benefits into the picture. Therefore it implies that code improvement is a frivilous task and should never be attempted.
However I believe it's cruical to constantly improve and refactor the code, because:
- Software development is itself a continuous learning process and without improving the code you can't get better at it.
- A team should be proud of their code.
- Future maintenance will take less time and over the long run savings will be significant.
Or do you think such tasks should never be created and such improvements performed only "on demand", "when associated with a bug"? Even if it's associated with a bug, wouldn't that be a discussion point on a code review, e.g. "why did you do this drastic change in structure?".