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.

In the last two years I have worked with a poorly written codebase of nearly 40K lines of code. Over that time I have made many small refactorings to improve it and made some bigger, as time permits.

Unfortunately, I still view the codebase as poorly written.

What's your experience? Do you think many small fixes can take me somewhere, or I have to stop and allocate a big chunk of time to fix things (of course, management won't be happy if I do this while we're working on the current "very important" new feature).

share|improve this question
    
Why is it poorly written? –  user1249 Apr 25 '11 at 22:08
    
Because the developers who worked on it were not quite careful to not make a monster piece of code. I just enjoy their legacy while they moved to greener pastures. –  Ignite Apr 25 '11 at 22:17
    
what exactly does "monster piece of code" mean, and what needs to be done? –  user1249 Apr 25 '11 at 22:57
    
Is there good unit test coverage of the existing code? If so, take bold moves... –  rwong Apr 26 '11 at 5:07

3 Answers 3

up vote 3 down vote accepted

My take is that refactoring is included in delivering new features. I assume that leaving good code behind me is an expectation of my job and seniority.

Therefore, in a case like yours, I would refactor as heavily as needed all the parts that are affected by any change, and include refactoring times in the estimates I give.

If your management does not understand the concept of technical debt—and the costs of repaying it—or does not support a reasonable amount of refactoring, you might be very limited in your current position.

You should never be asked to deliver crap code, within reasonable limits. If you are, then the standard retort is "Why don't you hire a junior programmer to write it? They will surely cost less than me."

share|improve this answer
    
Alas, whoever replaces me will hate me for what will seem to be inexplicable jury rigs added into otherwise clean code...Though, if my boss outlasts me, likely the poor bastard will understand. –  Satanicpuppy Apr 25 '11 at 22:02
    
@Sat: Erm, what do you mean? :-) –  Sklivvz Apr 25 '11 at 22:06
1  
tl;dr: my boss is an idiot. He can't tell people that things they want are stupid, so I end up grafting on features that are so outside the spec that to integrate them correctly would involve a total rebuild. And the development cycle is brutally short, so I end up grafting these ridiculous abortions on to otherwise clean code, and I know in my bones someday someone is going to curse me for it. –  Satanicpuppy Apr 26 '11 at 0:44
    
IF nobody else in your organization sees the need to refactor a poorly-written codebase, or if they see the need but can't ever do it (i.e. always creating new features so there's no time allocated to go back and fix the bad stuff for the future), you're going to be in for a rough time. Speaking from personal experience here - if you're the only one who sees a problem, then you're never going to be able to fix it. My advice would be to simply learn what you can, and move on when a better opportunity presents itself. –  Wayne M Apr 26 '11 at 13:36

40k lines of code is pretty small, but if it's critical code, it's still a significant investment of time.

We'd all like to be working on sexy wonderful code, but the business case is always based around return. Does it cost you so much time per year, that you'd save time by putting in large fixes? Or does it work well enough that you can't justify the time?

In my experience, programmers all want to replace their predecessors' code. It's a strong temptation (because they're all incompetent/crazy/drooling morons) but if it's working, leave it be. Try to focus on your code so that the next person to hold your job won't feel the need to re-write it.

share|improve this answer

I think many small fixes can take you somewhere. I don't think you need to set aside a big chunk of time to refactor even badly tangled code into good quality.

Look at where you are and where you started. It was bad originally, and it's bad now - but is it better? My guess is that it is. It may not be improving as fast as you like - it never is - but if it's improving, and continuing to improve, then you're already on the right track.

share|improve this answer

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.