I am Siva, a passionate java developer, open source enthusiast, blogger. I like to cover Java, Struts, Spring, Hibernate, Ajax Tutorials, How-To's and Best Practices. Sivaprasadreddy is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

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

02.22.2012
| 905 views |
  • submit to reddit

 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?

 From : http://sivalabs.blogspot.in/2012/02/do-you-have-defect-id-to-burn-hours.html

0
Published at DZone with permission of Sivaprasadreddy Katamreddy, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)