Usually when I program, I have a clear task ahead of me, but find annoying things I'd like to clean up as I go on.

Here I see three options:

  • Do it later (may forgot/have to spend time adding a ticket)
  • Do it now and commit it together with my current work (unclear)
  • Do it now and the commit it separately (have to find it, might make a mistake and go for option #2 unintentionally)

This is probably fairly basic, but what are some ways to circumvent this using svn/git/other?


2 Answers 2


Personally, I think it depends :-).

  • For small fixes, option three (now, in a seperate commit) is best, because the overhead of doing it later is not worth it. In that case, you just create a separate commit. How to do that depends on the VCS you use, and is a separate question :-).

  • If it is a larger fix, you create a ticket. Otherwise, you risk constantly getting derailed from your main task ("Oh, look, another opportunity for refactoring, oh, there's another, and there, and there...").

  • For your first bullet, small fixes, commiting the edit immediately seems like the best option. I have no idea why I hadn't thought of that, bad habits I guess. I do tend to get a bit into the coding part of programming, as opposed to the code-management part :) Commented Dec 3, 2015 at 5:27
  • @Nattfrosten: Yes, that's natural, and not bad - after all, the focus should usually be on coding. The code-management ist just to make coding easier.
    – sleske
    Commented Dec 3, 2015 at 15:36

Consider this. When you "find annoying things (...) to clean up" and you make an executive decision to do so, you're cutting the rest of your team out of a priorities discussion and decision. You're letting your agenda trump everyone else because of your privileged relationship with the code. I don't think that's nice. From experience, it also leads to team/shareholder resentments.

Instead, create an issue/task for the clean-up/refactoring. While it's fresh in your mind, list the reasons it's important: estimates of increased stability, ease-of-maintenance, that sort of thing. Maybe include an estimation of effort depending on how your team works. Then in your next task selection/assignment/priorities meeting, present your refactoring task and position it against other tasks. As a team, decide when it should be completed.

Please don't think I'm telling you to throw out good sense in the name of principles. Use your head. If there's something ugly in the function you're editing, it's not a new refactoring task. Fix it and check everything in. If renaming the property you're working with to something more sensible affects a couple extra source files, it's not a new refactoring task. Fix it and check everything in. If, on the other hand, you don't like the way another developer (Mitch, I hate that guy) did something in a function you're not editing and said function appears to be working fine, leave it alone for now. Create a refactoring task and present your case to your team.

If refactoring is always down-voted by your team in favor of new features, start looking for another job. It's easier to find a job when you already have one.

  • 1
    Thanks a lot for this reply, so far I've mostly been involved in solo projects, so that's where my perspecive came from. I will have to change a lot of habits to better fit into a team later on, and this kind of thing is just what I needed. Commented Dec 4, 2015 at 5:58
  • Same conclusion, but it is often the bosses that decide to go for new features and not refactoring :-|
    – Mark Hurd
    Commented Dec 9, 2015 at 4:14

Your Answer

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

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