How to estimate a change on a maintenance project?

Question

I was put in charge of maintaining, alone, a project that I never worked on before, altough I just received this task, and just started to look around the code, management asked me how long it would take to implement some new features and bugfixes. How should I evaluate this, what´s the better approach? Should I evaluate the time to "just make it work", or consider extra time to refactor some (a lot?) of code smells.

I guess the main thing is, how do you estimate changes on code you have never seen before, and would you try to "improve" the existing code, whithout knowing how long it would take or what could happen?

EDIT: made it more clearer, that I´m just beggining to analyze the code.

Answer 1

If your management will accept it as an answer, give them an estimate of how long it take to give them an estimate. You need time to examine the code and its structure.

Also I would ask if this is a short term situation or will you have to maintain this code for an extended period? For short term I would just do the minimum to "make it work" as you put it. If this code will be around for awhile and you or someone else will need to continue to add new features in future, then I would allow some additional time for rewriting. Even then I would restrict refactoring to critical sections and sections you are working on. It is seldom worth rewriting large amounts of legacy code.

Answer 2

I don't think you can responsibly or reasonably give an estimate on code that you've never seen before (although in the previous paragraph you mention that you're "still looking around", so I'm not clear which is the case). Refactoring should certainly be put off if there's pressure to complete ongoing development, unless the things such a godawful disaster that adding a feature for anyone who isn't the original developer requires the services of a delphic oracle and a cryptographer.

• If you can't understand the code at all, I don't think you can estimate
• If you have some access to the previous developer your task is much easier.

Answer 3

Software development estimation is very difficult, and doing estimates for a code base you've never seen before is nearly impossible.

Whatever you do, don't give an estimate of "just making it work". Just getting something to work is the easy part. The hard part is things like taking care of edge cases and fixing weird bugs found during testing. The hard part is what will consume the majority of your development effort.

I would ask management for a period of time to learn the code before being asked for estimates. You could spend that time fixing the minor bugs and learning your way around (these two tasks go well hand-in-hand).

Then, as you move up the learning curve, you could start providing estimates for things that you feel comfortable estimating.