15

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?".

Improve this question

6 Answers 6

Reset to default
16

Typically I do not like to view "code improvement" activities as a seperate assignable task because code improvement itself never directly brings you closer to completing user stories or requirements. This is why code improvement tasks will always be such low priority that they never get assigned.

I see code improvement as a constant, something that every developer should be doing as naturally as typing on a keyboard. I factor it into my estimates for any task. If my task involves me touching a class or some source code that hasn't been looked at in a long while, then I will assume that some janitorial work is probably in order and increase my estimate accordingly.

Best case scenario I finish the task early and can use the remaining time to improve upon code or even design. Worst case scenario the task takes much longer than expected but I have that extra time as a buffer.

Improve this answer
6
  • 4
    +1, as soon as you see code improvement as a task by itself, you ends up with crappy code, because it is alway low priority. Just don't consider other tasks finished as long as the code quality isn't good enough according to company standard. Doing code review is mandatory here.
    – deadalnix
    Mar 8, 2012 at 16:19
  • 1
    @deadalnix Excellent point about code reviews. If they are done from the beginning then code quality is theoretically maintained by default. With maintaining legacy applications though this isn't always the case and code improvement must be addressed as you go.
    – maple_shaft ♦
    Mar 8, 2012 at 16:23
  • 2
    With legacy code, the best way is still to wrap it in a clean interface to not spread the crap all over the codebase. Then massive unittesting the wrapper, so we are sure we can rely on it, and eventually touch the legacy code if required without collapsing the whole project.
    – deadalnix
    Mar 8, 2012 at 16:28
  • 1
    +1 Particularly for "If my task involves me touching a class or some source code that hasn't been looked at in a long while". You should only improve code that needs to be changed. If it doesn't imminently need to be changed, leave it alone.
    – MarkJ
    Mar 8, 2012 at 17:22
  • 1
    For especially large projects and teams, it still makes sense to keep code improvement as a separate task - there's only so far a single developer can go while working on a new feature. Usually I'll reserve 2-3 weeks a year for my team to implement improvements and refactoring (in practice, turns out to be longer, as, usually, only a subset of the team can be offline at any point in time)
    – blueberryfields
    Mar 8, 2012 at 21:54
2

If you want to refactor your code, set the priority of the task according to your definition (i.e. "how it impacts the product"). Some refactoring will not impact the product much and some will, depending on the scope of the work required. Setting a higher priority will indicate that more testing will need to be done after the refactoring is completed to ensure nothing unexpected has occurred.

You may also want to introduce a new category in your bug tracking system to categorize these kinds of tasks as "Refactoring" tasks. This way you will know how to interpret the priority value; that is, higher priority means larger impact and therefore more testing required.

Improve this answer
1
  • 2
    To add to that, technical debt (from lack of refactoring) does impact the product, because it becomes harder to maintain and introduces more possibility of bugs. Once the product is impacted, the user is impacted... In our team, we have "Improvement" tasks which we use for refactoring, and process/tool improvements
    – Atif
    Mar 8, 2012 at 16:52
2

What is missing is verifying your assumptions about the existing code: less time and significant savings can be achieved if we improve the code. Is this cosmetic or are there serious issues?

Check your debugging and enhancement estimates. If they are taking longer and there are continuous comments about having to refactor the code first or clean it up, that may be your best measurement. Then you can identify your code base as: Good, needs minor rework or serious refactoring required.

All of this is relative. It is difficult to give this high priority when there are customers wanting more features and willing to pay immediately for the billable hours.

Improve this answer
1

Interesting question.

I think you'd have to estimate how many lines of code and how many modules that a change might affect.

Maybe you could look at how many unit tests, if you have them, will get broken by making the change. This would probably mean trying the change in a branch first to get an idea.

Then have thresholds for these matching levels priority and severity.

You should also take into account have much tester testing will need to be involved. If the change touches a large surface area of the app, then a lot of system testing may need to be revisited.

Improve this answer
1

Let's start with two assumptions here.

  1. For every new story, you write your code to the best of your ability, possibly shored up with the ambient knowledge of your team.
  2. Whenever you have a story that changes the functionality of existing code, you use your new knowledge of the system and better skills to improve the code in the process of implementing the new story.

Given those two assumptions, there is never a need for an explicit "code improvement" effort. Your code improves as you write the system. This means that not all of the code is up to your latest and greatest standards for maintainability but "If it ain't broke don't fix it." I consider refactoring code that doesn't need to be changed to be "gold plating" as much as adding unneeded visible functionality. If the code is broken in some way, write a valid test that fails; log a bug; and then refactor to address that bug.

Improve this answer
1

I would steal voting from the Agile movement:

Enter the bug, make rough guesses for severity and priority,

Then, daily, weekly or monthly review all the new bugs, and vote on their ratings. Ideally you do this during a sprint planning meeting with end users. Then you can talk about the next features at that time too and be positive,

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.