0

My manager gives me tasks to build a program around. After giving me the task, and making any changes to it, he asks me how long it will take. I realize this is an important question for managers. I'm new at software dev and not sure how to answer this. I've never coded the task before, so I don't really know.

I find the time taken can be broken down into 3 parts 1) understanding the task 2) building the program 3) trouble shooting / fixing bugs (I've heard, and agree with, that most of the time in development is spent trying to get the already existing code to work).

noteme123
  • 509
  • 5
  • 8
  • I'm voting to close this question as off-topic because I think it belongs in programmers. – Lawrence Aiello Aug 06 '15 at 19:55
  • Your boss must be new to his position if he expects a novice to know how to size a job. At your experience level he basically wants you to "schedule a breakthrough", i.e. do something impossible. Were I in your place (and I have been), I'd say "I don't know. I don't have enough experience yet to be able to size the problem". That might not be what he wants to hear, but it's honest, which is the safest thing for you unless he's incompetent. – MMacD Nov 22 '16 at 19:51

1 Answers1

10

Below is my original answer to a similar question on Programmers. I think that it entirely applies to your situation. If you have any further questions, feel free to leave a note - I can add additional explanations.

From The Pragmatic Programmer: From Journeyman to Master:

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

In the section, the authors recommend the following process:

  • Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
  • Make sure you understand what is being asked. Determine the scope of the problem.
  • Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
  • Calculate the estimate based on your model.
  • Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
  • Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
Community
  • 1
Thomas Owens
  • 21,779
  • 7
  • 80
  • 101
  • 3
    And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project. – HLGEM Aug 06 '15 at 19:38
  • 2
    And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking. – Kent A. Aug 06 '15 at 19:42