Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Earlier, I asked to find out which tools are commonly used to monitor methods and code bases, to find out whether the methods have been getting too long.

Most of the responses there suggested that, beyond maintenance on the method currently being edited, programmers don't, in general, keep an eye on the rest of the code base.

So I thought I'd ask the question in general:

Is code maintenance, in general, considered part of your daily work? Do you find that you're spending at least some of your time cleaning up, refactoring, rewriting code in the code base, to improve it, as part of your other assigned work? Is it expected of you/do you expect it of your teammates? Or is it more common to find that cleanup, refactoring, and general maintenance on the codebase as a whole, occurs in bursts (for example, mostly as part of code reviews, or as part of refactoring/cleaning up projects)?

share|improve this question
add comment

6 Answers

up vote 13 down vote accepted

If you've got legacy code I think it's often pragmatic to clean-up or refactor code when there's a need to dive into that code e.g. to fix a bug or add a new feature. Otherwise you risk wasting time or breaking code that was never going to be maintained again anyway.

I wouldn't usually dedicate time to cleaning up code for the sake of it but rather while working on a bug/feature a good rule is to always aim to leave the codebase in a better way than you found it.That is in terms of factoring and test coverage.

When you're writing new code you should endeavor to have it maintainable from the outset.

share|improve this answer
6  
+1, it's the boyscout rule. Leave your camp a little better than you left it. –  CaffGeek Feb 3 '11 at 22:19
    
yep, agreed - managers hate when you tell them you want to spend time "just refactoring". If you do a little as you go you'll be a good boyscout! –  Ozz Feb 4 '11 at 14:40
3  
@Chad, don't you mean: "Than you found it." –  JD Isaacks May 24 '11 at 18:02
    
@John Isaacks, indeed I did...unless you have a time machine of some kind...then my sentence could work. –  CaffGeek May 24 '11 at 19:36
    
Do make changes in its own commit, separate from the bug/feature. See programmers.stackexchange.com/questions/183840/… (Maybe except for legacy code for which reviews might be less of a practice.) –  Lode May 8 '13 at 15:42
add comment

It depends. Early in a project's lifecycle, I am literally all over the code, cleaning things up wherever I see them. As we try to stabilize for release, I do less and less of that. The next time that product is in a development cycle, I will another (smaller) round of cleanup, then stabilize for release. As time goes on, I try not to clean up except where I am adding a new feature or fixing a bug, simply because of the risk of making those types of changes. I have a good number of unit tests, but still, there's a risk each time you do "cleanup" on an app that's in production.

share|improve this answer
add comment

In my current project, it is part of my daily work. I have refactoring tasks scheduled fairly regularly as part of the normal development work. I tend to focus on some specific areas and do larger scale refactoring in about a day long chunks, spread over several months. On the average, I spend half to one day refactoring per every two-week iteration.

This is (surprise surprise) a fairly large legacy project. It had been outsorced to several different subcontractors, and 2 years ago it was at the edge of the abyss, full of bugs, very unreliable, with very unhappy users (rightly so). That's when our team took over and started the lifesaving operation (I joined the team about a year later). By now the situation is way better, but there is still a long way to go.

Luckily, our management understands the situation and knows that we need to pay back a huge accumulated technical debt, so they allow us time to do regular refactoring and acknowledge our effort even when it does not result in tangible, visible changes for the users. They know that this is a business critical app and that they need to invest in its long term maintainability, instead of trying to save short term costs (they tried that, saw the results and learned their lesson). In this sense, this is a dream workplace. In all the previous legacy projects I worked on, the state of the code was more or less the same, but management was far from this level of understanding.

share|improve this answer
    
+1 for a cool management that realised the importance of long-term maintainability. It gives hope to us all :) Even 1-1.5 days dedicated refactoring per two weeks is a lot imho. –  Alb Feb 3 '11 at 22:37
add comment

Follow the boy scout rule, leave any piece of code you touch in better condition than when you got there. This should be part of daily coding activities. You can also run metrics against the codebase using various tools. But the best method is to make it part of the daily activity.

share|improve this answer
add comment

Of course it is. Anyone saying otherwise works in some alternate universe.

share|improve this answer
add comment

It's part of daily work, but a lot of smaller companies won't like to admit it. There it's all about new features, innovation, things that they can charge a client for.

It's kinda hard to charge clients for maintenance of your own code base when they haven't requested it and get no tangible benefit out of it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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