How can a Developer Estimate Times? 227
SubliminalVortex wonders: "Many times in the past, I have been asked on 'how long' it would take to implement a certain features/fixes in a product. What's interesting is that many times, certain 'fixes' is adjusting the wording/placement of the items in question; in other cases, users want the product to do everything they ever imagined, since it already started by following their line of thought. From there, the problem continues. From the user interface, people 'imagine' and think that 'oh, it would be easy if...' and scenarios occur, not only internally from the company using the product, but the clients themselves. Usually, several good ideas are there, but estimating times is a pain in the arse if you have a platform you're writing code for which has no documentation. How do coders estimate times to their bosses? If I know the answer outright, I'll give it, but in some cases, I don't how much time I'll take from other developers *because of the lack of documentation*. I'm going to have to bring in my D&D dice next week just to start."
No Easy Answers (Score:2, Interesting)
The best approach I've found is to decompose the problem into chunks that are small enough to give a reasonable estimate of, but I've hit two snags with this:
1. it may take time I don't have to do the decomposition
2. managers don't like big numbers
Good luck!
My one-time mentor taught me well (Score:2, Interesting)
One hour becomes two days. A week is two months. A month is two years.
P.H.: If you are reading this I'm still in the business.
A nice article by Joel Spolsky (Score:3, Interesting)
This might help: Painless Software Schedules [joelonsoftware.com].
Re:Scrum Development Process (Score:3, Interesting)
Yes, but it's better to know in two days that your estimate is wrong than wait thirty days. Also, a lot of SCRUM is breaking things down to an understandable level. I.e. down to problems like, "Design the initial schema for the main database table" rather than problems like "Define the database schema for the project." It's much easier to determine how long it will take you to write up a practical first draft for a single table than it is to do all of
1. Determine all the data your project will need.
2. Break the data into normalized chunks.
3. Select indexes to optimize query performance.
4. Denormalize to optimize query performance.
Note that the first step is completely open ended. Does your project need one table? Ten? A hundred? Waterfall development processes try to guess this ahead of time. E.g. if most projects average about thirty tables, then that's what this will need. If you only need ten, then you have too much time allocated and over examine the database schema. If you need a hundred, you allocated too little time and miss your date.
The third and fourth steps should actually be done *after* you've started working with sample data. SCRUM allows you to push out problems like this. Waterfall forces you to guess. This leads to duplicate work. Further, every step after the first is dependent on the first. Thus, if you misquote the first, you misquote every step after it. With SCRUM, you openly admit that the first step is not all you need to do and then stop worrying about the rest.
Another advantage of SCRUM is that if you put too much into the current iteration, you can drop stuff. Then, when you do the next iteration, you can pick some or all of that back up with revised estimation. In Waterfall development, you're forced to rewrite the whole estimate every time you do that. With SCRUM, it's just part of the work you would do anyway (you already knew that you were going to plan out the next iteration).
Partial agreement... (Score:5, Interesting)
The last thing you ever want to do when asked by a manager is give a off the cuff answer. It will almost always be wrong.
So what do I do when I get asked how long something will take? Well, to start off, if I know the code in and out, and I'm aware of the bug, then I can actually estimate what amount of time it will take. If it's not a bug, but something to be developed, and I've done the exact same thing before in my career, I already know the answer.
If however, neither of these are the case (which is about 98% of the time), I say this: "It'll take me roughly x hours to investigate this matter further and only after that will I be able to give you a timeline that is accurate."
First off, that gives you way more credibility, and way more leeway. But second, it lets you dive into the situation without having committed your life to fixing it, until you get a better grip on what's going on. If I were for example dealing with a bug on a web app (the kind I regularly work on these days), I would say something like "It'll take me 4 hours to investigate". I will most likely start with about an hour spent understanding the scope and possibly the history of the bug. "Is it reproducible?" is the most important question. If it is intermittent, I will commit to nothing at this point. If I look at the code and can see what is causing the problem, that is, if I can see a clear cause and effect chain that agrees with the test cases etc, I rely on my prior experience and make a guess at how much code needs changing. Plan for it, and plan conservatively. *DON'T* rewrite the application. Only fix the problem.
If you have time left on your initial x hours, start fixing the problem. See how it goes. Does it look like it's just going to keep on going like this until you fix it, or are you finding your being faced with odd and quirky behaviour left right and center? If you have weird behaviour, beware! If you have undocumented libraries/APIs behaving weirdly, beware! Don't get caught with your pants down. Let your manager know that you are passing some data down to the J2EE/COM/.NET/.Salsa/<NameYourCustomFramework> and that it is not acting as expected.
For actual development, the process is slightly different. Assess what needs to be done exactly in the same way as above (give an initial x hours to investigate). See what actually needs to be done. *DON'T* rewrite the STL library or .NET framework to do it. Choose the quickest cleanest path with the least amount of development time. Look at all your prior experience: have you previously used STL? Do you know it like the back of your palm? Have you only briefly used COM? And have you had issues with it the times you did use it? Keep that in mind. Try to steer the project in your domain of expertise. Put that as a coefficient in your estimation. If you know you have 100 lines or so of code to write using a library that you know in and out, estimate what you think it will take. If you will have to use a library that you're not really familiar with, pad it like crazy. I mean 2-3-4 times what you expect.
Those are the practical comments, there's also the more theoretical stuff:
Don't confuse accuracy and precision. And don't let your managers confuse the two. If I am asked to guestimate a project timeline, saying "4 months, 3 weeks, 2 days, 5 hours, 23 minutes" is more precise but radically less accurate than "4 months". Yeah, it sounds stupid, but accuracy != precision. Don't forget that. Tattoo it on your hand if you must. The longer a duration, the less precise it should be. Commiting to February 5th is ok if you are in January, it is not ok if you are in August. If you are in august, you must commit to a month coming up, and warn your managers to give it leeway. Just cause you said "it'll be done in february", doesn't mean they should plan a launch on February 18th.
The other thing is a little concept that I really like in comp sci algorithmics: divide and conqu
Re:Design the feature out (Score:2, Interesting)
I have a sentence for this: I can't remember the future.
Re:Design the feature out (Score:3, Interesting)
If you can't reach that point without actually writing code or lots of pseudocode- either your designing skills need work (they aren't detailed enough) or you need to get a feel on how long it takes you to do simple things. If its the later, one way of fixing that is writing down when you start and stop tasks and seeing how long it actually takes you.
IT's not documentation that you are missing... (Score:5, Interesting)
It could have been the whole XP process or whatever, but personally I believe it was the testing that allowed us to estimate so well. When something is so well tested, and when you are working from a "test-first" mentality, you get the ability to estimate what you think it will be without having to fudge-factor the results. You do this for a while and you find that your gut instinct gets better and better.
Re:Ah, time estimation (Score:2, Interesting)
Hmm. Then why, depspite years spend working under PMs who'd taken all sorts of courses, have I encountered so few who could deal?
Then the problem is trivial. What about the general case?
And it seems that no one has yet come up with a good answer outside the trivial case.
Re:Ah, time estimation (Score:2, Interesting)
The problem you're ignoring is when the lack is not in skills or expertese, but in information about the problem.
You can't break a problem down until you throughly understand it. Gaining that understanding is problem in itself. How long will it take you to learn to grebnesk? You can't make any sort of guess until you've started to understand grebnesking.
It's like digging a well - you dig until you hit water. How deep will you have to dig? If the area is geologically unknown, you simply can't make a prediction. Maybe feet, maybe 600. Now, once you first hit water, then you can give an estimate on how long it will take to complete the well.
Any interesting software project is digging in unknown ground - if the ground is known, we just re-use or adapt someone else's implementation(s), and the task is fairly trivial. That's what makes software different than building a bridge.
Asking how long an interesting software project will take is often more like asking "how long will it take to find a cure for this disease?" or "how long will it take to write a novel?" than "how long will it take to build a bridge across this river?"
Read a book! (Score:2, Interesting)
He recommends that you create two or three estimates: the best case, the worst case and the expected case. Using three estimates will give you several advantages:
- you express the uncertainty in your estimate to your managers
- Using some simple statistics you can calculate a much more reliable overall estimate (the errors in individual estimates average out if you combine them into a larger estimate).
But most importantly, he claims that the single point estimate you and I have been giving is in fact the best-case estimate. If you read the book you'll see that it is guaranteed to be impossible to hit the targets we set based on those single-point best-case estimates.
Re:Scrum Development Process (Score:3, Interesting)
I'm still leery of the distorting effect of reporting, though. If a manager's credibility or ability to act is negatively affected by his developers' daily reports, you can be sure there will be pressure to stop hindering his work. As a developer, I appreciate whatever gives me the widest scope to tackle a problem directly and honestly, and having day-to-day results disseminated beyond technical personnel has always had the opposite effect.
One advantage of traditional project management is that it gives techies a layer of insulation from management politics; they can be completely honest with their manager and trust him to suppress any information that could be used to sabotage the project. Many developers fail to demonstrate the most basic level of political competence even when they spend all day thinking about it. I include myself in that bunch. If it comes up, I tell my managers that any plan requiring me to be politically sensitive is a bad plan.
Perhaps Scrum is just poorly suited to my particular strengths and weaknesses, but I consider myself a pretty typical developer. I value my career over any company's success, I prefer complete honesty because I have never succeeded with any other strategy, and when management turns on bully mode, I just do what they want and call it their loss. That isn't to say I don't value my integrity, merely that I protect my integrity by choosing my working environments very carefully, not by martyring myself if I end up in a bad situation. Putting guys like me out there in front of assorted stakeholders with many people's credibility dependent on our statements is liable to bring all kinds of pressure on us to account for political consequences when we do technical work, and we will not stand up to it very well. I imagine Scrum being of value only in businesses that can depend on esprit de corps to trump politics.