Do you have defect id to burn the hours spent on code refactoring?

Working on a large legacy code-base is challenging(painful?) and is inevitable.
You may need to keep on refactoring the legacy code to fix bugs, to add new features or enhancements.
For these changes normally we would have a defect or new requirement created in QualityCenter/VersionOne or whatever the tool you use for tracking the tasks. We burn the hours spent on these tasks against the respective defect-id or requirement-id.

Then assume you identify some piece of code which is written in horrible way and thought of refactoring that logic. Generally we will create a defect-id explaining the need for refactoring and refactor, test, commit, done.

In some organizations, as per process every commit to the source code should be associated with some defect-id or requirement-id.

What if your manager said

As per our process, every commit should be associated with a defect/requirement.
We can create a defect for code refactoring that you are suggesting. Every code change should go through all the QA/UAT cycles. But the business will prioritize the defects/features for the next release as per release plan. So I can’t assure you whether this will go in next release or not.

I guess you can understand what that manager’s reply implies :-).

But I felt like from the manager’s perspective it is valid point. His target might be to deliver the planned bug-fixes/features for the next release.

So guys, I am curious to know how is code refactoring is happening in your organizations?

3 thoughts to “Do you have defect id to burn the hours spent on code refactoring?”

  1. We perform refactoring mostly when its required for an enhancent or bug fix, and associate it with that id. Sometimes we have larger, more independent refactoring jobs that get their own id and in that case theyre schedules into the release plan

  2. Depends on the size of the refactor. Small stuff just gets done, catch the boss in the hallway and say "code X is pretty crappy, I am going to fix it". Bigger refactors get a bug ID so QA knows they need to give a solid once over. Probably would be best to have a bug ID always so QA knows something has changed in an area.

    Refactoring generally improves things but there are times when it really messes up some odd program logic that you did not know to test against as you were doing the refactoring.

Leave a Reply

Your email address will not be published. Required fields are marked *