views:

882

answers:

13

As a new developer who is the only software guy on staff I have faced a few challenges but possibly the most difficult has been time estimates. I strugle every time I have to give a project estimate.

My question then is; If I do not have any experience and I don't have a fellow dev in my environment, how do I provide a solid estimate? I have read Joel Spolsky's article on Evidence Based Scheduling but how can that apply if I do not have any evidence?

I appreciate any advice on this subject.

+5  A: 

You are allowed to say "I don't know, I don't have enough evidence"

Then do some prototyping to get some evidence.

Then answer the question.

So you may in fact be able to give an estimate of when you will be able to give the estimate.

DanSingerman
usually there's parts of the request you have done and can estimate on - separate those out, prototype the others (try not to spend more time then needed) and provide an est. with the disclaimer that you are x% sure of the time. (usually you want to be somewhere in the 75% when you are sure)
meade
+17  A: 

You don't provide a solid estimate. You give as good an answer as you can, and explain that it is just a very rough estimate, and why it's so rough.

If you make it very clear that:

  • You can't give an accurate estimate
  • It's entirely reasonable that you can't give an accurate estimate because it's different work to what you've done before
  • You'll update the estimate as time goes on and you get to know the topic better

I think you should be okay. You need to make those things very clear though, in writing, so that you don't get held to your rough estimates later.

Jon Skeet
I disagree. Programmers can, and should, provide real estimates. You can't run a business based on "it will be done when it's done."
John Dibling
@JohnD - Do you have any advice on how I do that for something I have never done? Thanks!
Refracted Paladin
I just posted. Let me assure you that estimating development work is extremely hard is you want your estimates to be worth anything.
John Dibling
John Dibling: I disagree. I am a junior developer that is often asked to do things that I have never done before. When asked for an estimate, I do just what Jon says to do here. I report directly to the VP of engineering and was told by him that he appreciated my candor.
Ed Swangren
...It is unreasonable to ask someone to estimate something that they do not yet know how to do. Let me ask you this: how long would it take you to write a functional networking protocol? Assuming you have not done this, how would you estimate such a task?
Ed Swangren
@John: You've just posted that you'll often have done 90% of the work before giving an estimate. Does that really agree with your first comment here? If you're not going to give an estimate until it's very nearly done, that's very close to "it will be done when it's done."
Jon Skeet
+2  A: 

I first base my estimate on my percieved complexity of the problem. How big is the problem. How many pieces might it touch or require. This gives me a general guideline. Then I always make sure I add a 15-25% fudge factor because you are going to miss something.

Finally you make it very clear that this is a rough estimate based on your understanding of the problem, and how you might solve it.

Also do not give any rough estimates in very precise increments. 4.5 hours is not a rough estimate. Half a day is a rough estimate.

JoshBerke
+1  A: 

IMO Joel is way, way off in his article, and his conclusions and recommendations are not based on any reality. (Sorry, Joel) Fundamentally he says that you should be able to schedule your work down to units of time of hours or less before you even begin. But the reality is you don't know what those units of work are all going to be (in non-trivial systems) before you get in to the code. So you can't come up with an hour-by-hour breakdown of what you're going to do before you even pop the hood and have that breakdown reflect what actually happens with any accuracy.

Giving a project estimate is very difficult if you want that estimate to be of any value. Coming up with accurate estimates is difficult for programmers because very often you don't discover all the complexities of the project until you get under the hood.

So the solution to this is to get under the hood when coming up with estimates. For smaller projects & bug fixes this is fairly straightforward:

  • Replicate the bug on your machine.
  • Find the code that is causing the bug.
  • Figure out how to write the code that will fix the bug.
  • Estimate how long it will take you to write that code.

In finding the code you have to write you necessarily must discover most or all the complexities that would have thrown off your estimate.

The interesting thing about this method is that the time it takes to generate the estimate is very often 90% of the total time to actually do the work. You practically have to do the work in order to come up with an estimate. With bug fixes especially, the solution is often on the order of one line of code, so your estimate will end up being 5 minutes. That's fine because deadlines can be set around estimates like that.

As you get practice with this you will get better and better at "just knowing" how long things will take. At first you'll only be able to "just know" how long the smallest projects will take. But over time you will be able to estimate larger & larger projects.

John Dibling
You just described the essence of evidence-based scheduling. You use previous experience to estimate future work. As you get more ond more experience (evidence), you "just know" (through documented experience) how long future projects will take.
JeremyDWill
@JDW: Thx. I had never hear it referred to as evidence-based scheduling. I actually thought mine was an original thought. :)
John Dibling
@john: I came to you and ask how long will it take you to fix this bug. let me know in 10 mins. Part of fixing of a bug, is finding it reproducing it etc, and in many cases takes longer then the actual fix.
JoshBerke
"The interesting thing about this method is that the time it takes to generate the estimate is very often 90% of the total time to actually do the work." At that point your estimate is near worthless. I think that method is effective for designing a new feature where there isn't much unknown
Davy8
By which I mean that you can figure out what needs to be done in the design process which is (generally) less than 50% of the total time, but for bug fixes for which you don't have an idea of what's involved, from a management point of view you might as well give a rough guess or a firm I don't know
Davy8
@Davy, as I said, you can run a software buisness based on "it will be done when its done"
John Dibling
+1  A: 

Personally, I imagine an estimate as a statistical distribution - and try to communicate the idea of standard deviation with it:

10 is 'it has a 50% chance to be between 8 and 12'

It's hard to get much more precise than that for overall project estimates. It is perfectly possible to get more precise (split into individual independent stories, collectively estimate each, and other agile practices) - but it has a cost.

(Also, an estimate should NOT be an engagement on deliverables - otherwise it gets padded to death and becomes useless)

ptyx
+2  A: 

Although it is very rough, I estimate on Lines of Code. This parameter, whose meaning for productivity is close to zero, still gives you an idea of the complexity of a project.

Measure the fact that on average, a developer can write circa 200, max 300 lines of code per day. Keep into account that just for coding of a single man army:

  • A small project of 1000 lines of (logic) code can be done in one or two weeks
  • An average complexity project of 10.000 lines of (logic) code could be completed in two or three months.
  • A large project of 100.000 lines of (logic) code requires at least a couple of years

To the logic code, you have to add the testing, which is already included in the previous estimates. To have a clue of the complexity, the Gimp is 600.000 lines of code, a kernel ranges in the million or more.

To this, add the fact that if you are working waterfall, the time you need to develop the code is actually a small part of the time needed to develop specifications and design. I would estimate a 2/3 time is for specs+design, and the remaining 1/3 goes in coding, maybe even more on the specs+design part. It is really time consuming.

So, track your estimate from the complexity, to the lines of code, consider the manpower you have and how much they can work in parallel, and add the overhead of specs+design, you will get a very rough estimate.

I suggest you the mythical man month. It is a fantastic book on this regard.

Stefano Borini
If you have someone coding an average of 200-300 lines of code per day then that person needs to learn some design skills, because they are doing a hell of a lot of copy and pasting. Doesn't that person test their code either?
Dunk
well, I don't totally agree. I personally coded an already fully designed application module. I just had the interfaces.The final LOC were 9200, and I wrote them in 45 days of work, meaning an average of 200 LOC per day. Of these 9200 lines, half was testing.
Stefano Borini
If you're writing 200 LOC/day you're not planning enough. I've seen some people averaging less than 1/day on account of the formal planning and test development phases required in high reliability industries.
Adam Hawes
Wel, the planning phase was not counted in the 45 days. it was just plain implementation of the interface and the tests. The planning phase actually took much, much longer, so if you include it, your LOC goes indeed down sharply.
Stefano Borini
How much of the 9200 did you write and how much was auto generated? And did you say you were counting the test code in your LOC? I never heard of anyone doing that. While it is possible to get that kind of productivity, I am certain the code/design/reliability will be lacking.
Dunk
None of them was auto generated. Of the 9200, 4500 were code, and the remaining were tests. The language was python. No, the design was indeed lacking when we first started working on the rather deceiving specs, but the signed off design was solid and nicely fitted the needs without troubles.
Stefano Borini
+1  A: 

If you refuse to give an estimate for something you have never done, you will probably do that all your life. First split the task as much as possible, this will help you clarify how you are going to do it. There is more chances you will be able to compare a fragment of the task with something you have done before. Don't hesitate to communicate your degree of certitude to your manager.

MissT
+1  A: 

For an experienced programmer, who at least knows the system and has a set of reasonable requirements in front of them, "i don't know" is not a valid answer. If you say you don't know your PHB will go off and apply their 1337 h4x0r sk1lz and make an estimate in the order of "that sounds like a piece of cake, how about 1 hour".

You should be able to break the problem down into a series of smaller problems you've solved before and come up with a reasonable number for each part. Point out that it is very rough and could blow out considerably once you get to full analysis of the problem.

They're called 'estimates' because they're rough. You get better at estimating by doing it more and learning to draw on past experience as much as possible. Remember to factor in contingency (interruptions, task switching, possibility of being sick, possible rework, etc). Usually adding 50% makes the estimate closer to the mark.

Adam Hawes
A: 

Provide a rough estimate and be really clear about that.

Identify a strategy on how you will tackle the project. Particularly identify pieces of the system you can deliver as working intermediate releases. Pay special attention at the closest of these you would be able to release fully functional, and if possible take the rest out of scope (keep a list of these and anything that comes up, to be scheduled as a follow up project).

Use short iterations. Consider/analyze how the intermediate releases fit in 2-6 week iterations. Take into account learnings this give you, and adjust the overall estimate.

Go on with the first iteration, and apply what you learn about the assumptions you made. How off you are in the early iterations usually point to a problem in the estimates. Resist the temptation of considering the deviation in the estimates part of the initial overhead, as you will probably be delaying the point in time where you realize the estimates where off. Note that I do understand/agree the velocity of the project increases over time, but thinking about that tends to hide/delay the issues.

eglasius
A: 

I do this all the time. ALmost everything I do is the first time. How do I estimate ? I guess! And then I guess again. And I keep doing that each delta-time interval that a schedule is reworked, because project plans are iterative and you only what you know when you are doing it. My guesses are pretty good tho because I have, after many many years, figured out what 'looks' easy and what 'looks hard'

Scott Evernden
A: 

Try Function Point Analysis. For CRUD stuff it gives good ballpark figures. It's main advantage is that it's based not on what you are going to implement, but on what the user has asked for. You'll need to find out what your FP productivity is, though. You can use past projects in the same language to do that.

You could use average productivity for the target language if you just can't build a historical dataset. It will give you something, not necessarily approaching reality, but will at least let you compare efforts for different projects.

Now, mind you FPA is bad on algorithmically-heavy software, and it relies on AVERAGES, meaning you'll probably overestimate or underestimate each project.

Daniel
A: 

my coworker always says, first estimate the project length, then multiply it by two add 1 and then add the next highest units. so if your answer is 3 days, then you would say 7 weeks. that's a half joke, one idea would be first estimate the project and then when its finished see how far off you were, maybe you are consistently off by a multiple of 2 or 3, or whatever.

iterationx
A: 

Any unknown task or job always has something which is known to a certain degree and easy to estimate. I split and I give estimates right away for the things I know and for the things I feel I know. The rest is honestly being declared as a thin spot and then we start "bargain". If work giver trusts my competence he will except my rough estimations and risks - we work together. It was never a failure, simply because I would never take a task which I can't lift or run into the ground (gut feeling?). If work giver doesn't trust me, I always recommend who to ask and where to look for a better option. Then we either work together or not. Most of the time we do, but everyone is on the safe side. I do my job, "thin spot specialist" gets his/her cut, managers are happy and customer's satisfied. Perhaps it's a bit naive, but it works for me :)

Dima