Slashdot Mirror
How can a Developer Estimate Times?
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."
The only way to tell is to design the feature, then guesstimate how long each part of the process will take (by comparing it to how long similar problems have taken). If there's a step you're unsure of, you need to be sure of it to give a reliable estimate. Then double it- something will go wrong, and its better to deliver early than late.
I still have more fans than freaks. WTF is wrong with you people?
The Estimator's Rule:
It always takes longer than estimated, even after accounting for the Estimator's Rule.
Two things really... you have to break your tasks down into small tasks with known dependencies to the point you *can* estimate times to do things. Once you get that far, experience (gut feeling) will contribute. After that, you give an optimistic and pessimisitic times to your boss. Example: If all these assumptions hold and these other three things happen on time, then the time estimate is one week. If this, this, or this doesn't pan out as expected, then the time estimate is three weeks.
To take a leaf from Star Trek just do what he always did. Say it will take 3 times as long as you think it will, and you will always get half that time to complete it. And if you get it done early you will be rewarded.
Win-win.
Count how many dumbshit managers with no technical knowledge you have over you.
Double your realistic estimate for each DM.
Skivvy Niner? Email me!
HEY! Look left just ONE MORE TIME!
For the most part, your ability to give an estimate on a change is a matter of experience. General experience will give you a rough idea of how long it would take to implement some random feature. Specific experience with the system in question will give you a much more refined ability to make an estimate. If you can't make an estimate, or you can only make a rough estimate, be upfront about it. Tell your manager or the customer (if you're the one working directly with the customer) that your estimate is very rough, and try to add as much buffer time as possible. Also, don't get into granular estimates when you can only give a rough SWAG (Some Wild-Ass Guess). If you think it'll take you an hour, say a day. If you think it'll take you a day, say three. If you think it'll take you three days, say a week (experience will tell you how much buffer to add). If you don't have enough experience with the system to make a good estimate, ask your co-workers for help. It's always better to under-promise and over-deliver than the other way around. Besides, while you may end up over-estimating some feature, chances are you also underestimated another one and the extra buffer time you don't need for feature A will be invaluable to finishing feature B.
To help you make better estimates, you should make sure you get a solid set of requirements from your customers. Time should be spent with the customer to determine exactly what it is they want (they may not be able to articulate it clearly), and whether or not there's already a solution they could use if they're only willing to change their process. Avoid telling the customer at that point whether something is "easy" or "hard" (and definitely ignore them when they suggest something will be easy -- they don't know the inner workings of the code, so how will they know if it's hard or easy? Changing a piece of text may look trivial, but may involve a number of external factors such as localization or legal that would turn a 5 minute fix into a two month battle). Take what you've learned, distill it down into a solid set of requirements, and take that back to the customer for sign-off. Once they've signed off, they don't get to change their mind any more for this cycle (however long that may be -- days, weeks, months, or even years, though hopefully not nearly as long as that). Then you get rough estimates from the developers based on their gut feelings and knowledge of the code base, and have them investigate deeper to solidify those estimates. At that point, you have enough to build a schedule, but allow for buffer time! A developer's 8 hour day may not be 8 full hours of coding. It may be 4 hours of coding, two hours of meetings, an hour for lunch, and an hour of "filler" for the cost of task-switching depending on how the coding hours and meeting hours overlap. Based on your experience with past projects, you should have a good idea of how much time per day a dev actually gets to spend on coding and use that to build your schedule. For example, developer estimates are all in 8 hour day increments, but you know from experience that developers average 6 hours per day of productive work. That means a 5 estimated days will actually take 6.7 real days, so use that as your buffering criteria. (BTW, six hours of productive work is actually high. In most cases, it's really closer to 4 or 5.)
Finally, don't forget QA. Just because a developer has confidence that he can implement a specific feature in one hour doesn't mean it won't take QA a week to verify all of the ramifications of that change. You really need to have your QA team working in lock-step with your dev team. Your dev team should write technical specs on the features, and your QA team should estimate impact off of those. The "agile" disciplines that are en vogue lately try to incorporate testing directly into the development process, which is good. However, that means that developers will be in charge of including QA costs on their estimates, which developers are usually bad about doing
As others have said, you should estimate based on similar tasks, and then overestimate before giving that number to management. But there's also something to be said for being honest. Most management types I've dealt with are just fine when you say "I don't know if the application allows us to make that change quickly, so let me do some research and get back to you tomorrow with an educated guess." It helps if every so often you come back to them before the end of the day and say that it was an easy change and you've already finished it. Finally, when working on more than a few things at once, I make sure there's a prioritized list that I'm working from that management is aware of (so they understand why the latest request will take more time) Also, I make sure there's regular progress on one or more high priority items. Management and customers always sleep better when they see forward momentum even if the deadlines slip a little. Spending a week with nothing to show makes them nervous even when things are on time.
Time estimation is part of project managment. A good course in project management will give you the tools to effectively deal with these situations.
Short and sweet, when asked to give an estimate (any estimate) ask them if they want the quick and dirty estimate now (which may be off by 1,000% or more) or if they would like a more accurate estimate. If they want the quick and dirty then use whatever method you use now to give them the estimate. If they want an accurate estimate then tell them you'll research the current state of the project, the development effort required for functions x, y, and z, and the resources required to accomplish the effort.
Then follow a good estimating process - there are many available in many books about this subject. In my case generally new projects are very similar to older projects, and are all built on the same foundations so it's easy to start with a list of tasks to get from point A to B, and list the resources and dependencies for each task. Link them all together, and then go to the boss and say, "Assuming that we have these people and these reources, the project will be completed x weeks from kick-off."
When (not if) the boss says, "Well it needs to be done by this date!" Calmy reply with, "We can meet that goal by either scaling the work back, or increasing manpower. Which is more suitable for this situation?" and so on.
The one thing you don't want to do (that all too many software engineers do on a regular basis) is over estimate or underestimate the work required. In either case the customer (generally your boss) learns not to trust your estimates. This is bad on so many levels, and is the main reason that so many software engineers work more than 40 hours per week on a regular basis - especially those that overestimate the time required trying to combat this (paradoxically).
A more accurate estimation process will include a frank discussion of risk and risk management. "This schedule is good as long as we assume the code base is well documented and follows reasonable coding practises." Then find out what the customer wants you to do if you find this assumption to be false. Give them the whole scenario - the risk may be low, but if the assumption proves wrong then perhaps the project schedule or resources just tripled. That may be too great a risk to take even if it's unlikely - so how do we mitigate that risk?
I could go on, but really this is a basic question that millions of people have asked for thousands of years. There are much better and more thorough resources to answer it. Visit your local library if your company isn't willing to send you to a simple three day project management seminar. They won't teach you much that's new, but they'll tie it all together and give you the tools you need to communicate effectively with others - most of the important stuff is being able to say, "I'll get back to you on that by thursday."
-Adam
Don't do it!
I'm serious. If we've learned anything over the past forty years, it's that trying to estimate software development time is a waste of time. Why? Well, for one things, bugs. To know how long it would take to find and fix them, you'd have to know what the problem was, which means the hard part's done. For another thing, specification flux. Most reasonable project specifications for non-trivial projects don't provide enough information to accurately predict how long it will take to code. And producing such specs, and using them, will take longer than the development would have taken in the first place. And, if that's not enough, think of Dilbert. Specifically, the one where his boss asks him "Will there be any unforeseen problems?"
I once told a client (a dot com) "I'll tell you how long this will take if you can tell me what you stock will be worth six months from now, four months after you IPO. And I'll be more accurate than you will. If you'd rather, you can tell me when the next two-day rainstorm will be." He hemmed and hawed, and basically refused to give any sort of number whatsoever. I said "Good, it looks like we've got a nice honest relationship going here. Neither of us is willing to lie to the other, or claim to know something we don't. So let's start prioritizing these features for the mock up."
Let me say it again: Don't even attempt to estimate development times.
So what should you do instead? Incremental development with frequent opportunities for feedback. Ideally, the users should be able to play with a nightly-build prototype whenever they want from the first week or so on. If they ask for a time estimate, tell them it will be done when they're happy with the result, and don't want anything more, or they're unhappy with the rate of progress, and call the whole thing off.
But don't lie to them, no matter how hard they push.
--MarkusQ
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
I once worked for an "XP" (extreme programming, not windows) shop. We had not a single line of documentation in our entire codebase. What we did have, however, was 100% test coverage (at the unit tests level, the functional test levele, and even at the customer-test level). We could estimate, as a team, the length of time it would take to implement every feature in a major product change up to six months out, and hit them all on the exact day we had said we would.
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.