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."

It just takes experience

[DaFork]

Just Google "software estimation" and you get a variety of ways of doing it (the most popular formal model is COCOMO). In the real world, most people don't have the luxury of doing estimates the right way. In my experience, the stakeholders want a good guess at first (aka SWAG, OOM, VROOM, LOE). They treat that initial guess at the high watermark and then expect you to either finish early if all went well or finish on time if there were problems.

How I go about making this initial guess is by breaking the project up into sub-projects and then creating a baseline estimate by determining how long it would take me to do each piece myself. I then determine which person on my team will be working on which piece and then adjust from the baseline for that component based on the engineer's performance level compared to mine.

Once I have all those man-hours calculated, I double it. This is now my code and unit test estimate. Finally, add 10% for project management and another 25-50% more for quality assurance.

It seems kind of loose, but it works for me.

Be Honest

[bhmit1]

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.

I'm a fan of the WAG method

[code shady]

You know, Wild Ass Guess.

The Personal Software Process

[QuantumG]

Go read The Personal Software Process [cmu.edu]. It's full of helpful, common sense suggestions that every programmer should know. Then go read The Team Software Process, which is a simple forward thinking way of getting programmers to work well together in teams. Then get really really depressed because no matter how hard you try at stuff like this, the software industry is so random and unpredictable that common sense is not all that common.

It's called Hofstadter's law!

[Anonymous Coward]

http://en.wikipedia.org/wiki/Hofstadter's_law [wikipedia.org]

This is what I do...

[voxel]

When I can't reach a 80% to 90% confidence level that I can give an accurate estimate I do something different.

I don't give an estimate how long it will take to develop said feature. Instead, I give an estimate as to how long it will take for me the give the accurate estimate.

So, for example, I will say, I need 3 days to write some test-code, do some reverse engineering, and try to get part of the feature in, and in that time I am 90% confident that I will be able to give an accurate estimate then how long it will take to fully develop the said feature.

It has always worked very well for me to upper-management, as long as you then come in with a good educated answer how long it will take you after your first estimate.

It's better than giving a blind non-educated answer the first time around.

List assumptions/risks, provide low/high estimates

[ivec]

As developers, we always have a tendency to think in terms of best case scenario. And once you voice that best case once, it gets very difficult to get out of a crazy commitment.

So *before* providing any numbers, make sure to list the assumptions that you are making, and the interferences and risks that may (and most likely will) occur:
  - other projects and assignments that will steal time and resources
  - spec changes and debugging time, customer interaction
Explain that you have an estimate in Effort-Days or Effort-Hours dedicated to the project, but that this is not the same as a Calendar-Day. With week-ends, holidays, admin tasks, etc, count 200-240 effort-days per year.

Explain that uncertainty remains on a number of tasks. You want to give your best-case estimate, but there are things that you don't know, but in practice best case NEVER happens. Provide a more likely estimate taking the risks into account.

Highlight the key risks and challenges being faced. Discuss ways in which those risks could be mitigated: does it make sense to create a first prototype (to check technical feasibility and/or get end-user feedback) ?
Or can hiring a consultant (that you would select) to help you with a specific technology (e.g. set-up that database back-end) help speed things up/reduce risk? (sometimes few hours here and there for a couple of days total is enough). Keep in mind that "throwing more resources" at the task often only worsen's a project's delay (training and communication overhead, etc).

Does not having a quiet and uninterrupted work environment interfere with your productivity? Point this out, make concrete suggestions for improvements.

MBA or not, your manager hopes to just get a number from you, and then bind you to it. Don't let this happen, but don't be confrontational either: you need to establish a teamwork.
It is not about you escaping any pressure from a commitment. But many interferences are out of your control, and Manager might be able to help keep those away.

It is in your mutual interest to have estimates that work. And this is also why you need to keep track of your progress, and notice deviations early on. Be dedicated, and act responsibly. Warn Manager of any delays and problems that occur, so you can rectify the estimated schedule (or the environment) together.

Hope this helps -Ivan

Painless software schedules

[pietschy]

I wrote a tool called Mr Schedule [pietschy.com] that's based on the Painless Software Schedules [joelonsoftware.com] technique described Joel Spolsky. I've found the technique works very well.

Cheers
Andrew

lots of factors are involved

[josepha48]

This really depends on lots of things, like, are you familiar with the programming language. Is the existing code something that can find your way around. How well do YOU 'read code'. Yes, 'read code'. I can usually read code like I read a book and get an understanding from it, but only if I am familiar with the language. It also helps if you are familiar with the business logic that you are dealing with, if there is any. Also are you creating new code or working with existing code.

Creating new code is usually easier to estimate, because once you understand the business rules, you should be able to code it and estimate your time.

Bug fixes, on ANY code ( don't care who wrote it ) can be trickey. It can often be a situation that if you fix one thing your break something else.

There is no real set formula I use, but if I think it will take 3 weeks, I'll say 6. I always double my estimate, and often 'fish' for scope.

Lastly there is nothing wrong with saying 'I'll have to look into that to give you a more accurate estimate. You should be able to take a day or two to get into the code and look at it and figure out enough about it to get an estimate of what is involved. We do this and we call them ballparks. Our ballparks tell how much time the developer needs + qa + spec + IT time + some other things in there. It is usually an estimate.

Then we write a spec, and in the spec we uncover more. Depending on the outcome of the spec and what needs to be added or dropped the bid can change. Also in the spec we identify ALL the programs that need to be changed. These are things that should have been looked at in the ballpark to give you a better idea of what to extimate.

It sounds to me like you are a junior programmer. This has nothing to do with your coding skills and everything to do with your project skills. There are many people who can code circles around me, but they can't always give estimates that are as right on as me. As such, take a look at your code. This should be done in a day no longer. Figure out how much time you think you need to spend on it. Multiply by 3.

After you do this a few times you can start to see how good you are at estimating time. If you estimate time and you are behind on the project, then next time multiply by 4. If you end up ahead of schedule multiply by 2. After a few projects you will be able to say without a doubt exactly how long it will take. Unfortunately some projects will be a range not an exact date, like it will take 6 to 12 months, depending on scope changes.

really though it takes practice to estimate time. Knowing your own skill level, your knowledge of the language and code base, and what other things will always popup, and lastly your interpution level.

I'm sadly the goto guy at my company, so my interruption level is high.

Big or small changes?

[Michael Snoswell]

For small changes you can generally guesstimate from exerience with that system. If you know the code well there's a better chance of being accurate. If you have to wade through someone else's code you don't know then be very generous (generally double your guess).

With all but the most trivial changes you need something in writing to confirm what is wanted - even just an email to restate what you talked about and put your estimate in writing. Get in the habit of this. You can talk about it then look at the code for 30minutes and make a far better estimate than being pressuried into giving an answer straight away.

On much larger projects the time spent on actual coding gets less and less and the time spend on specifications, prototypes, testing, documenting, reviewing etc gets much bigger. I recently worked on a $250m sw project where coding was about 20-25% of the time. It depends on what the code is for. Normally coding is about 40% of a project but the more critical a system the less time spent on code and the more spent on design and testing. I've worked on some safety critical systems (ie where someone dies if your code is wrong) and coding was about 10% of the project. This might take a lot of joy out of being a programmer but it pays to get it right!

Re:Scrum Development Process

[Eustace Tilley]

What if you can't accomplish anything meaningful to the stakeholders in 24 hours?
[...]
If I reported anything else, I heard, "Why the hell are you reporting something to me that I don't understand?"
[...]
Alternatively, how do you persuade [nontechnical stakeholders] to show up every day just to hear Bob and Mary and I say "Important stuff, but nothing you'd understand" when they ask what we've accomplished?

The Scrum process requires meaningful-to-stakeholder progress every 30 days, not every 24 hours. The 30-day period is called a "sprint." What the stakeholders consider meaningful is completely up to them, so differences in the perceived value of fixing an awkward API in a library do not arise. Sounds like magic, but it's just process. The stakeholders and the development team agree before each sprint on what the increment of value (as measured by stakeholders) will be. For example, "we will achieve end to end throughput beginning with a 50 line dummy data input file and ending with three ugly but functional developer-specified reports. We will also meet with these end-users and prepare the first draft of their report requirements."

At the daily scrum, "why the hell are you reporting something to me that I don't understand" is out of order. The manager may ask only "What did you do, what are you going to do, and are there any impediments." These questions are to be addressed in concrete terms.

Dramatic simulation

Developer 1: "I reduced the argument count in the core library API and conformed the argument order and checked it into the mainline."

Manager: "From the looks on their faces, I believe other developers may have questions about that, so please have a work meeting after this scrum. Also, yesterday you said you were going to review the API, not change it. Please use these meetings to give advanced warning. Also, after the work meeting, will you please tell me what an API is?

Developer 2: "I created a warpo input file with known-bad items, including obsoletes, wrong currencies, randomly-scattered minus signs, a few 75,000 character fields and everything else my demented brain could come up with in an hour. By the way, the system now responds to negative zipcodes by rejecting them rather than freezing."

Manager: "Could you put that last sentence in correct form? We're trying to make the process visible, not just list benefits."

Developer: "Whoops, old habits die hard. 'I fed the warpo file to the system and observed the consequences, then changed the hyphen-parser logic in the zipcode field.' Today I will investigate why the system stopped compiling in my workspace after I integrated the latest changes from the mainline, starting with Mr. Speedy's core library changes. My impediment is that the security patch applied to the database server yesterday afternoon invalidated all the test passwords, and the system administrator is swamped with update requests."

Manager: "I will contact him and try to get you bumped to the head of the queue."

Finally, the only people permitted to speak at the daily meeting are the people who have committed to delivering. Others may attend, but must remain silent. The nontechnical stakeholders can satisfy themselves that their technical people are on speaking terms and possibly assist in removing impediments.

He was just misled by the conviction that developers should be able to report concrete (i.e., understandable to a non-techie) progress every day.

What you can report every day is your actions and your intended actions. "We drove 325 miles yesterday, 150 in the wrong direction, 150 back, then 25 ahead" is an action. Reporting that as "We progressed 25 miles yesterday," though less embarrassing, hides far too much. Checklist management - "what did you accomplish" - is appropriate for "defined control processes" such as taking inventory in a warehouse or assembling several floors fu