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.
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.
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:
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.
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.
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:
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.
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)
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:
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.
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.
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.
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.
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'
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.
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.
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 :)