0

The PM of the company I work on, always asks me to estimate maintenance issues and since there are several legacy systems that I didn't build, makes this hard to get. He says getting estimations for every task is necessary to have a clear plan, since I'm involved in projects and maintenance tasks.

Do you guys have the same problem?

Kcire
  • 9
  • 2
  • [How can I quantify the amount of technical debt that exists in a project?](http://programmers.stackexchange.com/questions/135993/how-can-i-quantify-the-amount-of-technical-debt-that-exists-in-a-project) – gnat Jul 22 '15 at 20:18
  • 1
    Please define maintenance? Is it refactoring- if so, I always pad my estimates to accommodate refactoring. Is it changes to sub-systems? That's part of the development, so you should be thinking of that for sure. – Alexus Jul 23 '15 at 00:02

1 Answers1

1

It's not difficult to make these estimates, it's just a lot of work and it you just need time. So the first estimate is that you need a day to find all the source files and to find out how many there are. Once you have all the source files and know how many there are, you can make an estimate how long it will take you to examine all the source files and create good estimates for maintenance issues. That's probably a few weeks. Notice that that's the time you need to make reasonable estimates, not the time to do any useful work.

So if your PM gives you that time to provide the estimates, then you are fine.

Or you just use brute force: If there is a system that you have never touched, but there are people around who know that system, and they can be interviewed, estimate 3 days to find your way around that system. If nobody is around who knows the system, take 6 days. If there is documentation how to build and deploy the system, add two days for building and deploying (because that documentation is surely out of date), else add five days. Two days for a bug fix, five days for a small improvemnt, 10 days for a large improvement.

Create a table of estimates and actual time to do the job. Once you've done a few jobs, use that data to fine tune your estimates. And always state very forcefully that these are estimates, and reality is stronger than estimates.

gnasher729
  • 42,090
  • 4
  • 59
  • 119