Slashdot Mirror
How Do You Accurately Estimate Programming Time?
itwbennett writes "It can take a fairly stable team of programmers as long as six months to get to a point where they're estimating programming time fairly close to actuals, says Suvro Upadhyaya, a Senior Software Engineer at Oracle. Accurately estimating programming time is a process of defining limitations, he says. The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization. Upadhyaya uses Scrum to estimate programming time. How do you do it?"
Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it. The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate. Once you start doing that, then you can adjust your estimates to allow for more features or yes.
This is my sig.
http://en.wikipedia.org/wiki/Function_point http://devdaily.com/FunctionPoints/
"when it's done"
6 x wild_guess + 2 weeks
I take the amount of time I think it will take, double it and move it up a time unit.
So, if I think it will take two days, I estimate 4 weeks. If I think it will take a week, I estimate two months and so on.
For me it really depends on how accurately they spec it out. If it is a general idea I can be an order of magnitude off easily. If it is a very accurate spec and needs little change throughout then I tend to be pretty accurate.
Write down all the possible times on bits of paper. Put on blindfold. Throw darts. There's your estimate. I'm consistently getting more accurate times than any other method.
How Do You Accurately Estimate Programming Time?
I'm sure there's a great punch line that goes here, but I just can't think of one just now.
Opening the floor for suggestions!
American Third Position
Finally, a real choice!
How do you do it?"
Equivocally. Like everyone else
I'll throw together a script that takes in all of the project parameters as input, then based on the number of people in the team, past performance, scheduling deadlines and intermediate deliverables, comes up with an estimate for final delivery.
Then I throw out that number completely, and just multiply the time it took me to develop that script by five. This method has proven disturbingly accurate.
You have to admit, there's some irony in "estimating" time with regards to computer programming.
:(
Yes, that's supposed to be funny.
/dev/random works for me.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I pull numbers out of my ass.
If I am ahead of schedule, rock on
If I am directly on schedule, rock on
If I am behind schedule, creatively blame something that is out of my control to begin with, rock on
I'm god, but it's a bit of a drag really...
I just make a wild guess and multiply by 2. Joel Sposky had a different take on time management:
http://www.joelonsoftware.com/items/2007/10/26.html
After 40+ years of programming it's still a Wild Assed Guess.
You're never given enough time to prepare your estimate, marketing has already
determined the delivery date, and management doesn't know what it is you're
supposed to create anyway.,
Nobody can ever give you a usable number. No matter how often you ask them. Instead, ask them for 5%, 50% and 95% numbers. These numbers indicate both the expected completion date, the amount of work they estimate and their feeling of worst-case, or uncertainty. When the three are far apart, that's a hint to you that it's not sufficiently clear & they need more data. When they're very close together or the developer refuses to give them, there's probably some pressure on him that would disadvantage him if he did - for example, knowing your response to his actual 95% number.
Show me a staff that consistently delivers products on time and one of the following will always be true:
1) One or more of your highest performers works extensive amounts of overtime (and is likely to burnout)
2) Project times are consistently overestimated.
It's a variation of the George Carlin Principle... People will adapt to fill the space, one way or the other.
( [Average copypasta time] x [Desired Lines of Code] / [Averages Lines Per Chunk] ) x K K = Constant of Desired Inneficiency
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
I just ask my manager how long he's already told the client it's going to take.
http://en.wikipedia.org/wiki/Hofstadter%27s_law
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
... if management is just going to come back and say, "Well, I told the customer it would be done by "
Seriously though, you might want to read, Software Engineering Economics by Barry Boehm. Some of the examples of work products might be outdated, but the concepts are still valid and useful.
Why should I bother to figure out how long it will take to implement it? Marketing has certainly already set a delivery date, so that burden is taken off your shoulders.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
But the folks who used the table in the lunchroom complained, so we now use the far more sophisticated system of tea leaf reading. This upsets nobody but the tea drinkers as we frequently need to user their cups before they're done, but then tea drinkers are wussies anyway.
Please do not read this sig. Thank you.
The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization.
My time estimates will be as accurate as your specs. You stick to the specs, I'll stick to the estimate.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Typically, the solution is much more malleable than time or budget. Determine the baseline requirements. Then determine the resources available (time and money). The project will likely fill the latter two. Success should be measured against adherence to the requirements, not time or money saved.
For fixed price, WAG*3
For Cost+, WAG*2
I do know what not to do. When someone estimates a programming job in number of beers, I get worried. If someone says that a security patch to an existing application is a one beer job, then I hope for the best, and that regression testing and QA catch anything new that cropped in.
If you think something will take an hour, change the unit to a day and multiply by 2
So
1hr=2days
1 week=2 months
and so on
Take my initial guess and either multiply by 2 and add a 0.
It is just like anything else. You practice, you get feedback, and you keep trying. That method should apply to getting better at both high-level and task-level estimation for any task (not just development). The methods that help you produce better estimates will develop based on experience and feedback. Historical reporting and adequate (but quick) data collection are key. While there are tools out there to help you determine where people are spending time, nothing substitutes for people estimating their work or the work of their team. Unfortunately, estimation is not valued in all environments, and can turn some developers off.
Are we estimating a tweak to an existing feature? Or the creation of an architecture for a high-volume real time production system?
That matters. Methods that are cost-effective for one are worthless for the other.
And there are other concerns...like....how much are we allowed to spend on the estimate itself? That will put limits on the accuracy and precision (the difference between which is critical to understand in any methodology), as well as further determine what kind of estimation methodology can be used.
In order to answer the question put forth in the summary, I will first need more relevant details.
My experience working both with huge and tiny projects has taught me this:
One size does not fit all.
I really don't know why this is as accurate as it always turns out to be, but it really works.
I look at the specs of what needs to get done, and I do a quick back of the envelope estimates as to how long each feature will take (e.g., feature A: 5 days, feature B: 2 weeks, etc). Then I multiply each estimate by 3 and add it all up. If some sort of hardware interfacing is required, I multiply the estimate by 8.
My supervisor for my Masters degree taught me this trick, when I was programming a sensor control system for a wind tunnel. I didn't believe him at first, but he turned out to be right.
Life is like a web application. Sometime you need cookies just to get by.
Times every quote by 10! How else will they think you're a miracle worker laddie?
1. Break the program into it's component parts.
2. For each component ask, "How long should this take?"
3. Multiply that number by three and record it.
4. Add up all the numbers.
I have used this method successfully for projects lasting only a few hours up to six months.
I will not mourn that which I never had to lose. - Unknown
Scrum is a way of chunking development into well-defined portions. The idea of using Scrum to estimate time just doesn't make sense. Everything in Scrum takes the same amount of time. Two weeks. (Or one week, or whatever your sprint length is.) The difference is that long projects are implemented over multiple sprints, since obviously, not everything can be done in two weeks. So the estimate is not of how long it will take, but how many backlog items will be required in order to reach some known endpoint. Once the backlogs have been created and agreed upon by the team, estimating the necessary time becomes a matter of multiplication: 12 backlogs * 2 weeks = 24 weeks to finish this product.
This makes you shift your thinking from "how long will it take to do all these things" to "how can I break this product development into chunks which each fit into a two-week period?" That's much easier than making wild-ass guesses about the time it takes to do something.
I make the initial best-guess estimates based on past projects and past developer performance. I track the initial estimate, and then I track all effort spent as it is logged. I.e. each checkin gets an "effort spent" number. I then track "actual vs. estimate" and come up with a total amount of overrun so far. I take that overrun, get a percentage (e.g. "over by 15%") and then add that back to the total estimate.
So, if the total estimate is 100 man hours, and we are currently over by 15%, I then say it will actually take us 115 hours total to finish the project.
This is based on the sage wisdom of Mythical Man Month: if you first estimate is off, so are all your estimates, usually by the same amount. As depressing as that might initially sound, it's actually accurate and it gives you a great tool for getting a real estimate once the project is underway.
So I mark my first estimates as "estimates" and then I consider the adjusted estimate once we are 2-4 weeks in to be more accurate. It has usually put us one to two weeks within the actual delivery date--which based on my experience with software development over the past 15 years is really good estimating :-) The norm on the projects I was a developer on was that overrun was closer to 90-100%. My last project I managed was 25% with new developers--I considered that a victory :-)
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
is to sit down and figure out how long it should take under ideal circumstances (no scope creep, no major fuckups, no outside holdups) and triple it.
That sounds awful, but it's almost always pretty close. Something always goes wrong, there is always some amount of re-work and there is always some scope creep.
In Soviet Russia jokes are formulaic and decidedly non-humorous.
Are we talking before or after the contract is signed?
I would advise reading "The Mythical Man Month" by Frederick P. Brooks. It is considered "The Bible" of the human elements of Software Engineering by many. By "human elements" I mean to include your request for information on estimating project time.
Here is a quote from page 20 of the book based on one portion of a software engineering project:
"In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing." (Brooks, 1995)
Citation:
Brooks, Frederick P. (1995) The Mythical Man-Month: Essays on Software Engineering: Addison-Wesley Professional, p. 20
Eagles may soar, but weasels don't get sucked into jet engines
Collect the relevant cartoons together and you'll have a fairly thorough treatise on the subject.
Here's the problem with the above, it assumes the functionality has no unknowns. Meaning, once you spec it out, it just a matter of design and code and everything goes relatively smoothly. I just spent a few days trying to get an image module to work in C# and Silverlight. The code worked fine, but no image. Finally giving up with beating my head against the wall and reading MS documentation, I posted a question on the SL forums. Silverlight doesn't support GIF - that was the image format I was using. Apparently, MS thinks that GIF is old fashioned and going away. Translation? All the examples and techniques were written for SL2, they wouldn't even compile in SL3 let alone work.
Anyway, how do you plan for that? You choose a technology, say Java Beans or JBOSS and the problem you get isn't easily solved with the platform or may not even be supported. You're on your own - gotta roll your own. And even then, can you do it in Java?
How do you plan for that? And it seams as though, every project is like that - there's always something that pops up that's a big question mark and the solution could happen in a morning or never.
Sure, a typical database application: data in, data update, data delete, etc.. could work very well with that planning technique, but some new product? Something that hasn't been done before or has been done very infrequently?
Look at past performance, adjust for scope of the job, triple it and add 30%. We programmers are always too optimistic. It's always the unpredictable 20% that takes 80% of the time.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
Software schedules are complex. There's a real part and there's an imaginary part.
A quarter-hour change will take half of a day. 2 hours becomes 4 days. 3 days becomes 6 weeks. A 6-month project will take 12 quarters, or 4 years.
It's eerie how often that rule of thumb seems to accurately depict the actual calendar time required -- eerily enough that when a so-called "realistic" estimate DOESN'T approach this metric, I find it's usually worth a second look.
Thankfully, at least at my place of work, this rule of thumb seems to break down once the unit of measure hits a year...
Agreed. The main complicating factor is the level of uncertainty:
I list the uncertainties, make a wild guess on each one, and finally triple the result. Historically I only successfully predict about 1/3 of the problems that are going to come up.
The hard part is justifying the inflated estimate when asked, since it's based on difficulties that I haven't actually identified yet.
Precise guess.
Accurate estimate.
In just one word: oxymoron.
I've found its only realistic to base a time estimate on how long it took to make a component (or something similar) the first time around.
Non sequitur: Your facts are uncoordinated.
For simple projects I can usually draw upon past experience. With complex projects, if the "client" was good about thinking through what they really are asking for, estimating the time needed is normally still pretty straightforward. But most of the time the client hasn't truly thought about any specifics regarding what they think they want, and will almost certainly bring up very involved new features mid-project - so in those cases I make a wild guess and then round up.
In all instances, though, there's another significant factor. If my boss is going to be materially involved in the project, I take my initial estimate and multiply by 3.
#DeleteChrome
By its nature software is always virgin territory. If it had been before then why are they asking you to do it? So its hard to estimate how long it will take because its never been done before.
Complete the programming job, then fill in the calendar when you are done.
I do the project first, then give them the estimate of how long it will take. For some reason, projects still take longer then estimated...
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
Just say "It will take between ${minimum_estimate} and 40 years". Chances are pretty good that this estimate will be accurate (and if it's not accurate you'll be retired by then).
Making an estimate both accurate and precise is harder.
I don't.
There are situations where I can take a wild guess but questioner must understand that a) it's a wild guess b) it only works in perfect world and if something goes wrong, and especially if that something is something I have no power over with, then you can safely double my bet. These situations are like if I'm asked to write some web based app for people who really don't know what they want. (Web based apps are for some reason really hard for me)
Then there are situations where I can take an educated guess. These are typically situations where I've written same kind of application before. These situations are starting to come more and more common now when I have ten years of professional programming experience behind me.
But if you keep gun to my head and demand exact estimate (can estimate even be exact?) then you could just go ahead and shoot me.
You don't know what you don't know.
Think of the time it will take in an optimal environment.
Multiple by 3.
Double it, and add thirty!
Modding "-1, Troll" is not a proper response if you disagree with me. Try reason.
Accuracy in estimating programming time? Last I heard, J.K Rowling hasn't written that book yet.
Ask any consultant and they'll say that it takes as long as we think we can get away with.
I almost always bill per hour. Most of the time my clients give me an email or verbal idea of what they want over the phone. I try to get as many questions answered as I can without wasting time.
I then take the task and break it down into as many bite-sized subtasks as I can. This does a couple things:
1. It shows where I have unanswered questions
2. It's easier to estimate "add 3 new roles to management interface" and "add cart admin role to admin interface" than it is to estimate "make admin area more secure".
Once that's complete (for this round), I put all those line items into a spreadsheet. I then estimate the number of hours it takes in a reasonable best, and worst, case scenario. So "add cart admin rold to admin interface" might be 3-4.5 hours.
I then add all those up, and add about 33% for planning, and 33% for testing/deployment. Sometimes it can be more or less depending on my experience with the client. I then give that spreadsheet to the client and say, I'm pretty confident your price will be within this range. The areas that have high variability are the areas we need to work on nailing down further. I will bill you actual time taken, but I'll let you know if the range is nearing the top number so we can re-evaluate. That almost never happens, or I should say that when it does, it's almost always because the client has asked for more work, and they understand this.
Customers almost always appreciate this approach and find it helpful. Most of the time I only do this for the first project for a client, and then they just ask me to give them a verbal idea of how hard the project will be since they trust me.
For the very occasional fixed bid work I do, I just take the high number, pad it a bit, and double my hourly rate. I tell customers ahead of time though that they are better off hiring me hourly in almost every circumstance. I usually don't spend a lot of time on fixed bid work because, frankly, I usually don't want it.
www.clarke.ca
Find out how much time you can spend on the project before you'd get fired for laziness, then subtract a day.
I am the richest astronaut ever to win the superbowl.
And probably more importantly than estimating accurately, we aim to estimate consistently. Then we compare actual rate of feature completion against the estimated size of remaining features. We've landed within a single sprint of estimates over a year long release with 20+ developers.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
What we do is try and break down tasks as much as we can so they each take 1 day or less to accomplish. Then it is easier to estimate a bunch of small task that most of the time have already been estimated in previous projects. Rinse and repeat.
Tired of my customary (Score:1)
Write up a one page document about the project, then go look at the code you are modifying. Make your best guess estimate, then double it.
I would recommend reading "Software Estimation: Demystifying the Black Art" [http://www.stevemcconnell.com/est.htm]. When estimates are created, there are many tasks besides "programming" that need to be done that are totally forgot about in the estimates and thus throws things off from the very beginning. We have to admit from the beginning that it is an estimate and is hinged with certain unknowns. If the unknowns are cleared up, we can be more accurate with our quoting (this is why requirements gathering should be done with careful attention). Also, since the estimates are just that, they need to not just be a number, but more of a range (if you have to give a number, choose the far end and be sure that you are confident that it can be accomplished by then - with a minimum of 90% certainty - and give the confidence with the estimate). One thing that I have learned is that I never negotiate on estimates/price, I only negotiate on functionality. If a manager/client wants it quicker/cheaper/less hours, fine, but I'm not going to change the number unless the functionality changes or more unknowns are cleared up (helping me to quote more accurately).
Take a look at Tom DeMarco's Controlling Software Projects. He deals with the issues behind estimating (including that one of the reasons we're so bad at estimating is that we get so little practice - much of what we call "estimating" is actually deadline negotiating). He ends up suggesting a separate measuring and estimating team - probably out of bounds except for fairly large companies, but the book has some good insights.
If you're trying to estimate the size of project for budgeting purposes, then function-point counting is a useful method. Over time you can learn how an organization performs and your estimates will become more accurate. If you're trying to estimate for the purposes of visibility then don't—you're better of using one of the agile development methodologies.
42
The units depends on what combination you want of:
now we need to go OSS in diesel cars
I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with Wideband Delphi, which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can download the PDF of it.
Also, Mike Cohn has a lot to say about planning Agile projects on his blog -- definitely highly recommended reading if you're trying to plan projects.
Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (The Perils of a Schedule) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).
Building Better Software
'Accurate' and 'estimate' do not go together well, an estimate is not accurate.
I can pretty much estimate, dead-on, how many days it will take me to write a script. The devil is in the details, though.
If the requestor doesn't fully comprehend what's needed, he will send back change request after change request after change request. Each request pushes out the estimate. For example, I once had a request to write a script that copies a log file from one machine to another. After the initial discussion, it was understood that the log file would be completed by 12:15AM every day. My estimate was 2 hours to write the script. And I did. It was a simple SCP wrapped in my standard shell template that took care of logging, reporting, and script miscellany.
The requestor tried it.. then informed that the 12:15AM deadline was not really true. The file may be written at any point, but each day the file gets rotated at 12:15AM. It wasn't the main file that was needed, but the one from the day before. OK, no problem. I took it as a change request and adjusted the estimate. Sent back a script that grabbed the previous day's file. Tried it in the test environment and it worked great.
We move it to beta test. This time there's more data. Now we learn that the application initiates the rotation at 12:15AM, but it doesn't necessarily complete by the 1AM when we run our copy because some applications still may be writing to it. I suggest creating a sentinel that the script can watch to only run when the copy is complete. Another long-standing issue comes up, however. The log can't run past 5AM otherwise something requiring human intervention happens. This has *never* occurred, but with anticipated increase in activity, it could shrink our window from 4 hours to just 1 for the copy. No one is comfortable with that.
In the end, the application is modified so that it writes to a shared filesystem.
I know... In a sane IT shop the lowly script writer would know the requirements before that first #!/usr/bin/perl line was written. In reality it's almost never the case. We get requirements and a deadline. We churn out code that matches those requirements. The project managers and the architects are supposed to give good requirements and conditions, but that rarely happens. Certainly we must anticipate certain events so we trap for the standard issues, but often scripts are just stopgap solutions to keep something going long enough until that component is redesigned or replaced.
Anyone used FogBugz' "Evidence Based Scheduling"?
A coworker provided me this formula, and it's the only thing that works. Take your normal estimate, let's say one week. Double the number, that gives you two weeks. Then, increase the timescale to the next unit, that gives you two months. That's your estimate.
1 hour -> 2 weeks
2 weeks -> 4 months
4 months -> 8 years
Done!
Joel Spolsky has a method which ostensibly accommodates for consistent over- or under-estimating by any individual developer. It takes a couple release cycles to collect the necessary information, then tries to use that data to provide a likelihood that a product will ship by a given date.
At some level, it will always be a WAG tempered with experience. It is always best to assume there will be delays and try to add them in.
The real catch though depends on what you're estimating. Just the coding or the design? When management says we want a program that does X, how long will it take, they're asking the impossible. They want you to estimate the time to get the actual requirements documented, the time to design software meeting those requirements (which you can't know until step 1 is complete) and then the time to build that design (that you can't know until step 2 is complete). You can guess, of course, and perhaps even be in the ballpark, but that's about it. TFA doesn't address this either (perhaps because it's not addressable beyond GUESS!).
Inevitably they'll complain that buildings get built on schedule all the time. They conveniently forget (or just don't know) that that schedule doesn't appear until the design process is completed (step 2 above) and before that, it's a guess.
The same as the construction industry. It will be done in "two weeks".
Seven puppies were harmed during the making of this post.
I take the average of my 'best case' and 'worst case' estimates then add 30%. Work out very well typically, what I'm really shooting for is to come in at a bit under the final estimate. Making sure that business understands that scope changes affect the estimate and documenting / communicating scope changes when they come up is critical.
Most of the time I'll guess until the business I am developing the software for agrees with my estimate. Seems if they don't like my estimate the first week, they ask for a new estimate the week after or even a day later to try and get a lower number.
Eighteen twenty sided dice. 5d6 for smaller projects.
All projects take 2 weeks to 6 months. Anything beyond 6 months is Duke Nukem Forever.
Some would recognize this as farmer speak for selling a blind horse, and after RTFM, where refactoring and work and revising guesses, the article called "Unskilled and Unaware" comes to mind. This article's basic premise is that people who are clueless tend to overestimate their ability.
In the old days, and with most engineering disciplines, costing is a quantified, factored skill. It is not an art. People with a great deal of experience, or whom have access to metrics, can cost building billion dollar chemical plants with reasonable error rates. It all comes down to experience, or metrics in another form.
First, you record how long it takes you to do something, and how complex it was, and how much risk there was. This knowledge can be used and applied to even unrelated projects. The biggest excuse I hear in software development is that we can't cost this because we haven't done it before. Bullshit. Remember design patterns? Someone has done it before. And it doesn't take much to figure out that something you are doing is either highly complex (and arguably requiring decomposition), or highly risky, and then cost it appropriately.
Then for those high risk items, apply a strategy like rapid prototyping, or spiral software (risk based) development practices.
Bullshit to the quality vs functionality argument too. The triangle of cost vs quality vs time or function does not take into account any of the elements for succesful project delivery, like experienced management, experienced leads, a positive working environment (read no asshole driven development), and people that actually think management is mo betta than leadership.
Rant off.
/\/\icro/\/\uncher
The differences in the quality and content of cost estimation handbooks for software and civil engineering disciplines are astounding. It's possible to take a detailed description of a building and come up with an accurate cost estimate; the books describe how much the material costs and the labor and equipment required to install it. Software engineering cost estimation books, on the other hand, can be distilled down to: "Using a process for cost estimation is good!" and "Use the result from the last time you built it".
For instance, compare the descriptions between these books. Look at the specifics given in the construction estimator vs. the fluff in the software estimator -- and keep in mind the latter was written by Steve McConnell, a well respected author in this field:
Granted, a handful of software is sufficiently bleeding edge that it's not possible to find and document past experience. But surely we've deployed database schemas, created servlets, written session handling code, etc., often enough to start documenting the typical tasks involved and how long they took.
Surprisingly accurate most of the time.
Edit: Hm, I hope that "<ol>" only looks that bad in the preview... guess I'm about to find out.
The best approach I've found is to build a domain object model consisting of only the objects that come straight from the problem domain and then multiply the number of objects by a person days to implement an object for the particular implementation technology. There are some adjustments you can make based on complexity of the UI and developer experience but the basic premise works. It's sounds like a simplistic approach but it's not because the process of building a good object model and that's a key point, the object model must be well done, this process is really a process of organizing the information you need to build an estimate in a very sophisticated way. An object model is a way to organize and account for all of the data and behavior of the system and furthermore, to organize the information into reasonable units. The rules around building a good object model will cause the objects to be of a fairly uniform size in terms of complexity. What you end up with is a list of discrete groupings of data and behavior with well defined interfaces between them allowing for the fairly simple calculation of an average number of person days per object.
Take each task and ask or determine at a team meeting the difficulty of the task...
Start with a base line for level if task difficultly (For example)...
easy task - one day
Medium Task - two to three days
hard task - 5 days
never done task - 1 to 2 weeks.
No task should ever been more complicated than a week and if it is then I try to break it down in to smaller parts. The only exception is the new task. I typically hand that to the guru and a week typically covers his research and implementation plan. But due to surprises I schedule an extra week. Some easy tasks turn into hard tasks and some hard tasks turn into easy tasks. The work week task is a nice policy as at the end of the week the individual task is typically done and if they get sick or something happens their work is caught up and someone else can pick their next task.
Then factor in the skill level of the developer - triple the times for a green guy, keep the same for a veteran, and cut 25% off for the mind blowing guru, etc.
Depending on the business culture add on a percentage for Testing. Then add on the typical roll out time. Good tester and fixing take about as long as the development.
In total I have about 5 levels of difficult and 4 levels of skills. Add on a bit of time for sickness, family issues, etc.
Most times we have time lines given to us. After the planning is done and if we can not achieve it I ask for more members or a reduction in scope or functionality. If they push and say it all has to be done then I ask for more money due to over time. If they still push I say it is impossible given the money, time and scope and demand they formally tell which corner should be cut.
I get it bang on or done slightly earlier at least 90% of the time. The remaining 10% of the time an easy task turned into a hard task or there was a dramatic scope change approved via a Change request with insufficient time to implement or unforeseen repercussions.
The big thing is to work with your team. In a group meeting lasting a few hours to a day you can determine what each task needs to be and determine the level of difficulty associated with it. Then you just need give ownership of each task to developer - this is good when some guy brags that he can accomplish a hard task in a day and the rest of the team disagrees (he may have insight or he is making a mistake). One of best examples I saw of this in action was the own project broken up in to major phases and under each phase it was broken up to more general tasks and under each task was a open box of the individual tasks required to accomplish it. The team then used sticky notes to put all the task in and a related difficulty level. The PM just facilitated the team and then recorded it all as the official plan. Every member felt included and felt like they had some ownership in the project.
no text
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
At my previous job I used the expression test. I would give the project manager a number, and if he scowled, I would give him another number. When his response was bored indifference, I knew I finally hit the right answer.
I rank the ego of the programmer from 1-10, then multiply their time estimate by that number.
mea culpa
I take the boss' estimate and multiply it by 5.
If it's my estimate, I'll multiply by 3 because I'm more in touch with the world.
Yours In New Orleans,
Kilgore Trout
If you just keep track of how long features take and who's working on them (like a bug/feature tracking system), a seat of the pants estimate based on complexity (i.e. this feature is 1/2 as complex, twice as complex) times the previous baseline data is surprisingly accurate and in general much better than if people actually try and figure out based on first principles. Basically people just ignore the base rate historical data for how long sw development tasks take, or don't know it. The other thing to avoid is telling someone a deadline because you will immediately induce an error based on the anchoring effect. Once you have a historical performance based estimate, then use that baseline (or anchor) to figure out what is practical for the project in question. Note: You have to keep track of things for 2-3 years to start before this works, which is why I suspect most people don't do it.
If you have a solid plan and experience in the area of the problem, double your estimate.
If you have a basic idea of what to do, but have to do some research, triple your estimate.
If you have seen it all, and know exactly how to do it, quadruple your estimate.
We're an agile shop and we do Planning Poker meetings and it's worked out really well. In addition to the cards (purchased here), there's apps for the various smart phones that some of us use.
The basic idea is that the features are discussed and each developer independently comes up with an estimate of the number of days that a feature will take. It's not really important if those days match up exactly with what can actually be accomplished in one day, only that developers keep that concept consistent across estimates. The estimates are revealed and we reach a consensus on the right number. Sometimes there's a large difference between estimates and the developers at the extremes talk through their thought process until a compromise has been reached. But most of the time, we're pretty close.
At first, you try to match those day estimates up with actual developer days. But, over time, you figure out how many estimated days you can fit into an actual time period (velocity). After a few iterations, the velocity becomes pretty reliable and you get to the point where you can easily figure out how much work you can fit into the time allotted. We do these estimating sessions and they usually take up about a day of the time of the entire engineering team (so 4 days per year.) For larger teams, it's probably possible to get accurate estimates with a small group of engineers, but since we're small, everyone is involved.
In the past year, we've only estimated 2 2-week iterations poorly. One we had unclear specs and were told late in the iteration that what we built wasn't really what was desired and the other was the result of a developer discovering a third-party library that saved us the majority of the work we had planned. Other than those two, we've been very close all year. If we're under, we pick up minor unscheduled bugs to fill the time. If we're over, we either subtract a day or two from the next iteration or a developer picks it up on the weekend before QA gets it's hands on it. But more often than not, we're dead on. I realize we're not perfect and there's probably a lot we could be doing to accomplish more in the time we're given, but the reliability of our estimates has been very helpful to management who values predictable development. They see us as highly competent not because we're able to accomplish impressive things, but because if we say we can do something, it gets done.
"Don't blame me, I voted for Kodos!"
Basically this is the slope of the line of estimated remaining work over a fixed timebox (such as an iteration or sprint). It's based on an application of the Central Limit Theorem and therefore it requires a few things to be in place in order to be accurate. I'm hoping to do a presentation on Commitment Velocity at the Agile 2010 conference in Nashville (link is to my session proposal).
Helping with organizational effectiveness is our job.
This is one of those problems, such as "the O/R problem," that cannot be solved because it asks an invalid question. I might suggest using it as a koan for Zen meditation.
The actual length of time a project will take arises from the complexities of the existing codebase as well as the rabbit hole of requirements. We can talk about the idea of a "spec" all day, but I've never seen requirements really, truly, set-in-stone finalized before release. Too many decision points always come up that were impossible to foresee without looking at a partially-complete version of the product. Requirements, like code constructs, are an adaptive process that continues all the way through the lifecycle, which is why the industry is flailing around for alternatives to the unrealistic waterfall model.
Thus, the set of actions that lead a team from beginning to end of a project are always, at least partially (and usually mostly) defined only as a function of the current state, and thus can't be fully predicted without actually playing out those actions. They can theoretically be partially predicted, but it's impossible to determine how large a fraction of the whole the resulting prediction is. It's almost never large enough to be considered remotely reliable.
Engineers themselves usually have a gut feeling that time estimates are a waste of time because of the need for this adaptive process. When was the last time you attempted a true end-to-end time estimate on a project where none was asked for by management? More than likely, you instead made a judgment about which path was probably the more efficient use of time, and started down that path with only a rough, order-of-magnitude guess at its length. At each step, your decision to continue was based on (1) how long it had taken so far, and (2) whether you continued to see a fruitful-looking path ahead.
I would argue that the common notion of time estimation in the industry arises mostly from the desire of outside parties (management) to create the illusion that the leaders are in control. I say "illusion" because ultimately, the main power here lies in the structure of the problem, not in any one person's hands. But the reality of being at the total mercy of a complex logic puzzle that can't be reasoned with would make most people very uncomfortable, especially those who are not in engineering. But the illusion of a "classic" hierarchical department with management and labor calms everyone's nerves and allows the workday to roll on, so we engage in activities that support it, including this charade of guessing the future.
Thus, searching for a good method of time estimation in mathematical models may help a bit, but ultimately won't get us there because it is fundamentally an emotional process. Look to the "soft" elements of team dynamics and department culture to do the rest: do people need to feel involved? Use a method where everyone contributes a number. Is the manager very controlling? Let him/her make up a number. Either way, there will then need to be a process of reconciliation between the illusion and reality, which again, is a process that depends on the emotions of the business. Perhaps a leader apologizes. Perhaps a "tiger team" is formed to improve estimation, or there is a department offsite to talk about it. It may feel unsatisfying that none of these actually brings the estimate and reality together, but like I said at first, trying to do that is asking the wrong question.
I like this methodology.
We break the project into use cases.
Estimate each use case.
Identify the risk of each use case (High = New stuff that may not work or is hard to predict, Low = Straight forward coding to implement).
Divide the work into time blocks (3 to 5 weeks, I liked 1 month increments).
Each month, measure actual progress against plan.
Another thing I do for my resources is to maintain an ongoing metric of whether they over or underestimate and apply it to their estimates. So eager girl who says she can do it it 50 hours but took 75, gets a +50% to her ongoing average. Meanwhile, cautious lad who estimates 80 and took 60, gets a -25% put in with his average.
I usually have a meeting with the stakeholders AND the developers to firmly establish scope and when scope changes, we renegotiate the deadline.
By putting the high risk items early (just do a proof of concept that Xserve 3.85 really does work under Unix 3.71 over a VPN connection before you commit 180 million dollars of dead end work to the project).
While I do not normally overwork my resources, if one of them bids 30 days from now to deliver, then if they have to work extra to make that date, then so be it.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Dice!
there are 3 kinds of people:
* those who can count
* those who can't
Two words: past data.
Estimation is something you will get better at with time, but you will get there much sooner if you have data to help you. Your first estimate can be a WAG (Wild-ass guess), but as long as you measure actuals and learn something from it the next time you estimate, you'll get more accurate.
Two methods which use this technique: Joel Spolsky's Evidence Based Scheduling (http://www.joelonsoftware.com/items/2007/10/26.html), and the SEI's Personal Software Process (http://en.wikipedia.org/wiki/Personal_Software_Process).
Oh, I'm _very_ good at it.
I usually meet or beat my estimates to accomiplish the specifications listed.
It's two things that can screw up a schedule:
1) The specifications are just not enough, and more really needs to be done to make it usable, and I want to do the right thing
2) The specifications are exactly what the customer asked for, but not what they want *now*
3) Documentation
4) Bad math
Design for Use, not Construction!
Software Development is a chaotic system. Essentially that means that small changes to the requirements can have impacts out of all proportion to the change. The traditional thinking was that because it cost so much more to fix issues at the implementation phase than the requirements phase that you should put far more effort into getting the requirements and design right.
The problem is that like a weather system it will be the small requirements change that is often most difficult. Not all small changes will have this impact of course, but there are some on a chaotic boundary. So how should we estimate projects?
I would start with performing a similar analysis as the old way; a function point count if you like. It does not need to be in depth however; counting the number of screens or tables or reports, or whatever else is fine. Its what we do with this data which matters. Rather than simply multiple the function points by some number of hours you should plot this metric against actual historic times to complete other projects.
This way you can see that based on a certain level of complexity you can expect a certain project effort. This system ignores some important variables. It assumes the same people are involved, and thus the same skills and productivity. Also it assumes the same number of developers.
What a stupid fucking question. Go do some research you ignorant twat.
The key to estimating software development time is to use historical metrics along with quantitative analysis. You don't want to be in a situation where you're just pulling numbers out of nowhere.
Define your problem and break it up into enough high level and low level requirements such that the entire software solution could be written by somone with no knowledge of the program using only the softare requirements. (This will vary depending on the size and scope of the software solution)
Using this data, you should be able to derive the size of the application in terms of SLOC (software lines of code), number of bugs that you'll likely found, and how long it will take to develop in terms of man hours/labor months/whatever using a multiplyer derived from past metrics. (ex: each Requirement = 25 SLOC, 1 SLOC = 1man hour, for every 100 SLOC there will be 1 bug, and it takes 8 man hours to fix a bug. You can also make allowances for particularly difficult learning curves, drop in productivity due to OT, etc, but this should give you a ball park figure.
If this is your first time and no historical data, there are plenty of software metrics available online (or if you work at a company, they are likely available there) for predicing SLOC, bugs, labor months, etc.
The more you use this process, the better your historical data will get and the more likely you are to have better predictions. They key however, is writing good requirements up front and keeping track of all time spent along the way.
That is, I don't accurately estimate programming time. The people here get pissed, but too bad... they give me a project, I say it'll take me x number of days, then they keep changing what they want and get mad at me when x comes and goes and I'm not done.
Oh well.
Stupid, sexy Flanders.
How long will it take for a computer program to halt?
Why this constant striving and pushing to predict the possibly unpredictable? And the demand to have those predictions be 100% accurate?
One of the things that bugged me about school programming assignments was how well behaved they were. If you were given 2 weeks to do an assignment, you could be pretty sure that's about how long it would take the slower programmers. The assignment was unlikely to be changed halfway through. Does school give the false impression that all such work is as predictable? Management is wont to suspect incompetence or laziness rather than understand that a problem is very hard.
Even if you have a well defined problem and well known tools, and you know the problem is not impossible, and that it isn't research into the unknown, you can still have a great deal of uncertainty. How long will it take to discover the next Mersenne Prime? Look at how long it took to discover the next ones in the past, starting from the first 2, known around 400 BC when prime numbers were first seen to be interesting. Maybe 200 years to find 2 more, about 1650 years, to Renaissance times, to find the next one, then 132 years for 2 more, and 184 more years for the next one. During this time, mathematicians saw that these numbers were interesting, although there was no direct practical use. The next batch of finds is out of order, illustrating yet another aspect of the unpredictability. The next discovery was 104 years later, but the next one in order took an additional 13 years. Then 28 years, and 3 more years for the next two. After that, it was 38 years, to when a computer was first used on this problem and found 5 more within a year! In the 58 years since that seminal event, computers have grown vastly more powerful. Our techniques have also improved in this time. And we've found uses for prime numbers, namely RSA cryptography. The result is that we've found 30 more, nearly twice the number that had been found in the previous 2400 years. Given that rate, we can estimate that the next one will likely be found within the next 2 years. But maybe not-- maybe there's a huge gap between the largest one currently known and the next one. In the past it has taken between less than 1 day to over 1600 years. Immense variation there. Or maybe we'll discover some magic closed form equation and we can compute as many Mersenne Primes as we want, so there is no longer any need to search at all.
Or, why this constant pushing for predictions with information that is much more uncertain than it need be? When no one even knows what is wanted, predictions are laughable. Garbage in, garbage out.
If I have good specs that have been carefully checked to make sure everything is defined, possible, and practical (sure, it's possible to factor any 1000 digit number, and it might even be very easy, but it might also take a very, very long time, and so not be practical), and I have tools that I know and which do not have any major bugs that must be worked around or fixed, or huge gaps in functionality that must be filled, then I can make a reasonable estimate of how long it will all take. But you know what? In the time all that takes, I could be off to a good start. Even when accurate predictions are possible, they may take a significant percentage of the time it would take to just do it, and so may not be worth doing.
Naturally, the closer a project is to done, the better the estimates can be.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I am sure somebody already said this: Read "The Mythical Man-Month".
Estimating requirements is very important and software engineers should attempt to improve their estimating skills. Overly optimistic estimates is the second highest cause for runaway projects. Consider a statistical approach such as FPA whose accuracy improves over time. Having to double your estimate is just a symptom of poor change management and other process immaturities. If you get push back on FPA because of its complexity, then consider rolling your own more simplified approach.
I use scrum too. But that's not a way of estimating programming time, it is merely a way to manage a software project. And it works. Use it. It's good for your heart and blood pressure:P
Anyway. Estimating programming time is actually really simple. You take your time to plan, up to 10% of the duration of the project, and discuss the result with your peers. Make a work breakdown and make sure there's nothing in there that you estimate takes more than about a day. Preferably much shorter. Also, use fixed ranges. I use less than 1 hour, 1-4 hours, 4-8 hours, 1-3 days and more than 3 days. The latter two are to be avoided. The result of all this is obviously a range you expect your project to take, not a fixed number of hours. Note that according to pretty ancient research, engineers often need 2.18 times their estimate to complete a task; this is sort-of built-in in the fixed ranges I mentioned.
Also, it is very important to keep a log of what you've done, how long it took and why. That's part of the reason it takes some time to get it right. Find entries in your log that look a bit like the entries on your work breakdown and compare them; that way you can learn from mistakes you made in previous plans.
So far for estimating. But that's only a third of the job. It is very important to acknowledge that what you've just calculated is just an estimate and to be open about it. So you need safeguards. I use the following:
1. Plan for overhead. 20% is usually fine.
2. Talk to your stakeholders and prioritize your project from a functional POV. Scrum uses http://en.wikipedia.org/wiki/MoSCoW_Method for that. Commit only to the requirements with the highest priority (and if that's all of them, just make up optional requirements:P).
3. Make sure your maximum estimate plus the overhead is enough time to fix those requirements.
The last thing you need to make your estimates turn out to be correct, is some form of project management. Make sure you discuss the state of the project (as compared to the original plan!) daily. Let all team members have their say and if something does not go according to plan, act on it early, don't safe the problems for release day. Make sure everybody has the right focus and works on the requirements with the highest priorities. Nobody should work on prio 1 requirements when prio 2 requirements are still not finished. Ever.
Obviously you're guaranteed to fail if you don't commit, integrate, test, build and package early and often. Use a continuous integration build-server, use version control, write unit-tests (yes, they safe time), use a proper issue-tracker (with workflow and support for estimates, actual time, priority etc) and make sure you have a quality assurance person on board that tests EVERYTHING (yes, that'll safe time too). Just the usual common sense stuff.
Of course some of us work on projects at companies that are run by douchebags; they won't give you enough time to plan, they do not want to prioritize, they don't understand why they need to pay for servers, issue-trackers, meetings, continuous integration servers, quality assurance ppl and all that "bullshit". Always share your concerns with them; never ever give them the chance to blame you. Blame them instead. And look for a better job that does not remind you of Dilbert; such jobs do exist;-)
Now if you stick to all that and evaluate early and often, you'll probably get it completely wrong the first few times, but you'll quite often get it spot on eventually. 99% of correctly estimating programming time is to get to know yourself and to stick to your plan. And those two things are incredibly hard;-P
0x or or snor perron?!
Just follow the government's guide book and you will hit the right number every time:
http://www.stsc.hill.af.mil/consulting/sw_estimation/SoftwareGuidebook.pdf
I am only half joking. I have witnessed several 12 to 25 Million Dollar software projects finish within five figures of the original estimates. The key is accurate historical data on which to base estimates.
1) Keep Task Descriptions (TDs) and Actual hours consumed working the tasks on past (historical) projects
2) Compare new project's task descriptions to historical task descriptions.
3) Sum the hours from the relevant historical tasks and make minor adjustments due to slight differences in tasks (Historical Basis of Estimate)
4) Multiply sum of hours times current labor rates to compute Cost for TD/BoEs and add a small reserve for the unforeseen
5) Multiply Cost of TD/BoEs times desired Fee to compute Price
6) Profit
I was skeptic too, but I have seen it work many times.
COCOMO II models are based upon SLOC (source lines of code) estimates. You plug in a bunch of other metrics, like the language, type of application, quality of coders, calendar, etc. What you get out is a reasonable estimate, built from the analysis of 1,000's of real-world projects.
"How many lines of code?" is often easier to answer than "how long will this take?" Is SLOC accurate? No. But, it's only a small part of the process. You can always factor out waste from guys you know are gaming the system. With a decent tool, you can even plug in actuals from previous projects for fine tuning.
It's very similar to other methods, but tends to be a bit more accurate... despite asking for lines instead of hours.
Make your estimation , than do that time x2 .
No matter how good you estimate things, there is always a chance things can go wrong , and the less room you leave for that , the higher the chance something will actually go wrong ( Murphy's law ? )
Slipping shoelaces ?
Steve Ballmer explains:
http://www.youtube.com/watch?v=R8xIdkw6Zvk#t=4m52s
Prisencolinensinainciusol. Ol Rait!
Hold scrum meetings, and then ask each developer and tester individually how long each step will take. Take their wild assed guess, compare it to what estimates you come up with in scrum meetings, and average those. Multiply that estimate by 2.25 to take into account vacations, side projects, meetings (which for some positions can consume 60% of your time, and you NEVER take those things into account when giving the project manager your estimate). Allow for some buffer time for bug fixes, fighting with Microsoft about hotfixes for libraries in which you find critical bugs when you're at the final beta stages, and also allow for some buffer time for having to issue emergency bug fixes on your released branch.
Estimates you come up with in scrum meetings and individuals' wild-assed guesses never take any of the unknowns into account. The engineers with no management experience invariably think "well, I work 40 hours a week, and I think this module will take me 120 hours, then another 120 to integrate into the project - so yeah. I can be done with my first phase in six weeks." That does not take into account sick days, dependencies (waiting on other developers for the components you need from them), time for getting sucked into meetings, time to rearchitect your piece when you find Microsoft's library doesn't actually worked as documented (or Microsoft's memory manager incurs eighteen gadzillion context switches per minute, slowing your process to a screeching halt under a moderate load) requiring you to invent your own or evaluate third-party libraries.
Always provide buffers to allow for bureaucracy/politics (read: meetings you are required to attend but you think are a complete waste of your time), unknowns (You don't know what you don't know so be generous here), and so forth. If you provide generous padding for these inevitable realities of corporate life, you can create a schedule which will allow you to come in on time and under-budget. If your project manager does not allow you to pad your estimate with unknowns, meetings, etc. but requires you to give an estimate based on 40 actual coding hours per week, you're getting set up for failure. That means no bonuses, poor performance review, and generally bad morale because your team will be "late" on a project based on a half-assed schedule based on fiction.
Even worse is when management says "Here is your next project: feature set is X, you have Y resources, and by the way, the due date is Z." Those are the absolute worst conditions to work under in development because management a) doesn't even know what out of X is possible, whether Y resources can actually accomplish it, and if even 1/3 of it can be accomplished within Z time based even on an ideal 40 hour workweek dedicated to writing code and doing nothing else.
By the way: do not base it on 40 hours of coding at ALL to begin with. You will spend 1-2 hours on emails, and a lot of time just engineering (actually just thinking the problem through) not to mention reviewing API calls you use and that time will easily match the time you spent coding. Plan on maybe 20-25 measurable "productive"[sic]* hours per week.
* "productive" meaning what a PHB considers productive, i.e., lines of code written, dialogs flashing on the screen, etc.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Isn't estimating the amount of time it will take to complete any non-trivial programming task just another version of the halting problem?
-- Give me ambiguity or give me something else!
Suvro Upadhyaya, a Senior Software Engineer at Oracle is a liar and a con man. Quite simple really.
Scrum is the latest in a long line of religions I'm sorry I mean methodologies that claims to achieve the unachievable. I propose a new advanced version of Scrum called Scrotum. It's the same as scrum but Ridiculously Overtly Titsup.
These posts express my own personal views, not those of my employer
What amount of time would cause the greatest harm to the largest number of involved participants?
I start by rating each coders “effective productivity” where for an hour worked, how much time/code actually gets generated. Some will be .5:1 if they have to stop frequently to answer questions, some will be at .75:1 if they code well, know what they need to do and are stationed in a broom closet so they aren’t interrupted, some will be .25:1 or even .1:1 because they are an intern or a new recruit.
Then I consider how long it will take to produce each section of the product (just broken down into logical groups) in a “perfect world” where everyone is coding at 1:1. I then apply each members effective productivity to that time for each logical group. I then add 20%-40% to each individual module I broke it down into, depending on how complete the requirements, specifications, etc are going into that module where 20 is better, 40 is worse (usually). So if I had five modules, time of each would expand by at minimum 20%+ the expansion of the effective productivity of those working on it. Then add all the time up, add 30% for testing then 20% buffer and you’ll find, surprisingly, you’re stabbing at a number that is as realistic as you can make it this early in the game. You also have a number that can be presented to those outside of IT and, dressed up with the math, presents an estimate that is based on real numbers and is quite hard to argue with. Ultimately, it’s a more formalized SWAG, all programming estimates have Some Wild Ass Guess in them though, as quantifying the time involved in being creative is quite hard to do.
I just had to give an estimate the other day. Not for programming, but for designing a program for others to write. As asinine as it is to estimate programming time, I think estimating a design might be worse. What I did was looked at the requirements and tried to figure out what the different pieces of the system were, then gave each one 3 weeks. That came out to about 10 months...which seemed kinda big to me, but how many people are guilty of over-estimating? As expected, the project manager thought that sounded high, so she found someone who she thought had more experience and asked him to help me make a more detailed estimate. Over the course of a week, we spent probably 5 to 10 hours pouring over the details of the project, breaking it down further and giving an estimate to each little detail. I let the "expert" give estimates to each piece. It came out to two years! (If I gave each of the new tasks 1 day a piece, it'd come out to 7 months) Needless to say, the project manager didn't like that either and wants me to revise it to make it smaller. I should just say "write down what you're going to say anyway and I'll make a plan around that", but I haven't.
Estimate the parts required using historical proxies based around size and content. Use historical development time data based on the part estimates. Consolidate the group of smaller estimates for yourself, or ideally across an entire team, to allow estimation error to cancel itself out as much as possible across the group. Now you have a solid estimate of the total effort required, and you just have to map that to the available development hours in each developer's schedule, rebalance as necessary, and see what your end date looks like. Team Software Process
Comment removed based on user account deletion
have a guess!
NASA recommends (almost requires) the COCOMO model. http://en.wikipedia.org/wiki/COCOMO I think the COCOMO model is used by the Software Engineering Institute (SEI) at Carnegie Mellon University as part of the Capability Maturity Model (CMM). As said in MANY of these posts, proper specifications/requirements are needed to estimate anything. My company uses it exclusively and we have been proven quite accurate over the course of many projects. http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
...as the way people think they can manipulate the estimates. It's like I give an estimate to bake a cake, then halfway into baking it they decide we only need a cake 80% the size, so that can be done in 80% of the time for 80% of the cost right? Everybody except project managers and clients would laugh at that, but it's happened in far too many planning meetings to count - particularly in response to overruns. If there had been complicated or expensive toppings that were easy to remove, they would usually already have been stripped in negotiations already so the estimates just don't work that way.
Live today, because you never know what tomorrow brings
Find out the liscencing cost for somebody else's implementation, get your budget written for 30% over that, buy the damn thing and get your ass to Maui. Quote two weeks on your way out the door and tell them you'll be coding it at home.
That's what my non-technical manager/boss tells me, so why should I bother doing anything different?
And puts a two week horizon on your creativity
Which is great if all you need to do is crank out grunt work, but a bit hairy if you are trying to do anything innovative that won't fit into a two week period. In creative organizations or fields of endeavor, nothing kills your chance of coming up with a great product as cutting things into two week deadlines.
-- Terry
You make a wild at guess at the time it will take. Then you double that. Then you add a week for bugfixing.
Then, during the schedule, if you start to get ahead, spend more time browsing the web. If you start to get behind, work extra and/or cut things like "unit testing" or "error checking". Do this as needed to deliver one day ahead of schedule. Then bask your reputation as an awesome scheduler.
The cake is a pie
The time it takes to designing software is way more unpredictable than the time i spend programming it.
If the design is all done then programming should be very predictable, but the problem is that design is never done well.
Imagine if you asked a builder how long it will take for him to build you a new house, but you dont provide a design, you just give him a list of features (fireplace, stairs, 2 bedrooms etc etc), the builder has as much chance of estimating time to build as a programer has of estimating time to write.
Now i want you all to repeat aloud;
DESIGN IS MORE VALUABLE THAN CODE, ;p
DESIGN IS MORE VALUABLE THAN CODE,
DESIGN IS MORE VALUABLE THAN CODE
My boss loves to change the freakin' spec midstream and near the end. I had my sanity before I started working here. It's a crying shame. My boss is the owner, the other coder, and the one pushing my buttons
When estimating an application, I break it down into much smaller pieces. Then I estimate each manageable piece, which usually can be compared to some previous known effort. I will also estimate complexity of each piece and if there is something that is not well defined, understood, or done before, then I overestimate that portion. You'll run under on some and over on others, balancing out.
I also use a multiplier on the total effort based on how well defined the application and/or requirements are. This accounts for time spend not actually writing code.
I've been told before that I am the only developer that people have worked with that has a less than 1 coefficient on developer estimates. Meaning, I get it done in less than my estimate. Whereas other developers typically need 1.4 (or more) times the estimate. This is usually due to the fact that with the above stated multiplier, I've already factored in the 1.4 times the estimate.
My estimates are typically higher than the next developer, but I have a positive reputation of consistently come in under estimate and delivering on time.
I think the important thing to remember here is that estimates are _estimates_.
Based on limited information about what the customer wants, the availability/productivity of the team (people get sick, have good days and bad days, ...), the bugs in the libraries you're working with, and the occurrence of disasters, you come up with an honest estimate.
It may be wildly wrong.
But that's your estimate.
Now, if the organization is going to raise that estimate to a sort of divine decree that The Project Shall Take That Long, and you'll only get resources for that many hours, and there will be a deadline which has already been agreed on with the customer, and you will get flamed if you miss the deadline (all these things are very likely), then perhaps you'd best not tell anyone your honest estimate.
Don't tell anyone how long you think it will take. Tell them how long you will need to be sure you get everything implemented, even if your team is sick half of the time, the scope keeps changing, and the libraries are so buggy that you'll end up spending more time than if you had written them yourself. Cause that's what will happen. And if, by some miracle, you still manage to finish early, that will be a happy surprise for management and a good mark for you.
I apply this technique, and while my colleagues always think my "estimates" are ridiculously high and what we end up reporting is usually adjusted downward a bit, it's spooky how often the ridiculously high numbers turn out to be right.
Please correct me if I got my facts wrong.
Clearly multiplying all estimates by 3 and then adding them is less efficient than adding them and then multiplying by 3 once.
Hey don't blame me, IANAB
Company president or management:: 15 minutes.
Engineering or Marketing: 2 Weeks.
Programmer or SysAdmin: When it's done.
Customer or end user: When it works.
Here's the advert to give to your HR department to hire the person for your 'estimating':
Looking for a BS or AS in the latest trendy programming languages developed by college students in their second year. Must have experience in legacy hardware as the most recent vapor-ware that everyone is buzz-wording about. Non-Discriminatory Affirmative action candidates preferred with background clearances and able to board an airline with a weapon. - Equal Opportunity Employer
- Dan.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
I have the pefect formula:
1. Estimate how much time it would take you non stop ...
2. Double that number to compensate for your ego
3. Divide it by the number of coffees you drink per day
4. Multiply it by the number of managers that talk to you per day
5. Multiply it by the number of meetings you have to attend per day
6. Double it if you have to use Microsoft software for any part of the project
7. Multiply it by the average number of loud conversations around you throughout the day
8. Add the size of your inbox in megabytes (1 meg = 1 day)
9.
10. Profit!
How do you accurately estimate programming time?
Answer this question, and you will know The Way: How do you accurately measure programming accomplishment?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Step one: Set up dartboard
Step two: Throw dart
Step three: You now have an estimate
Anticipate your customers' needs. Write the code first and have it working, and when they come to you with an idea and a request for an estimate, give them the time it took you times 3 plus 20%, and then spend the "estimated" time in a hot tub at a resort with your girlfriend while your customers are happily awaiting the results of your "development".
See? Programming *can* be fun! :-)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Accurate. Time. Estimate. Pick Two.
Seriously, I can't do it. I can give you any of these:
But, I have never, in 25 years of programming and project management, found a way to tell you accurately, in advance, how long a non-trivial task would take.
Writing computer programs (at least in my experience) is not like building a house. Every new project is a voyage of discovery in which we invent a brand new thing. You may as well ask Edison how long it will take to invent the light bulb.
Is that including or excluding the time they spend on /. ?
I have always used a Markov process such that development time will end up being within several days of : The summation from 1 to the total number of development tasks of the gamma of the summation from 1 to the number of developers of the zeta of the probability of the risk of ruin of a,b times the base-two log of the probability of the risk of ruin of a,b + one month. Kindof like this give or take a few bits.
You don't. That's why they are called estimates.
"GOLUB'S LAW OF COMPUTERDOM: A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long." Seriously, I was once told a project absolutely had to be done on time, within 8 months, and to do what ever I needed to get it done. the previous project had been three times the scheduled completion time. When it was done on time I was slagged for being 10% over a "budget" I had never seen. Fzck the suits! No wonder 80% of "business" is nose to butt.
I seem to recall a Buckminster Fuller making a comment about "a good definition being ninety percent of the solution to a problem." It would support the "Design is more valuable than code" viewpoint.
Getting that good definition front end can be a pain though.
I have a rule that has served me well -- whatever I seriously estimate for a project's duration, the first half will take 80% of that time. Then half of the remaining project will take another 80%. After that, half of the remaining project will take another 80%. This regression continues into perpetuity. Eventually, it is decided to declare the project complete and live with what got done. Therefore, I have always planned a product to only encompass that which could be done in the "first half" of the project. If that was not enough for the product, then it was not feasible.
Another rule of thumb for tech products, if the project slips more than 50% beyond its targeted release date, then break up the team. The team that slips this much will never keep up with the market.
... are you generating these estimates?
If you know your customer and you know how they state problems, provide requirements, understand the process they've asked you to work, then estimating can be done with some confidence.
If you've got a new customer, or a clueless one, then you've got to get involved in an iterative discovery process. You have to boil requirements down to something you can estimate, design and build to. But the problem here is that the effort for initial requirements distillation process can be rather indeterminate. And in a well managed project, its important not to skimp on this initial project stage.
So I guess my answer is: We can give you a very precise estimate. But we don't know how much time or money it will take to generate the estimate.
Have gnu, will travel.
Sometimes I think that the 'suits' will end up destroying the American economy in their pursuit of short term profits at the expense of things like ethics, employee loyalty, the environment, customer loyalty and the middle class.
my $quality = 100;
my $initial_project_time = length($piece_of_string) / ($count_programmers);
my $real_project_time = ($initial_project_time + ($scope_creep_time * $count_non_it_business_staff)) * $3.14;
if ($slave_driving_boss eq "yes") {
$real_project_time = $real_project_time / 2.5;
$quality = 60;
$bugs = random;
}
With a stopwatch!
You can estimate time only if you know all required components upfront. You should know all the related technology, which probably been used by you in prior projects. Once you try that no one managed to complete before you can't estimate what can be done in a single sprint.
Let's you have an NP-hard problem which is, e.g., a variant of set-cover or bin-packing. You write a prototype that maps the problem into SAT and invokes a state-of-the-art SAT solver, all is well. Next week you try to solve a set-cover instance, after running for a couple of hours you terminate the run. After tweaking the set-cover to SAT converter for the rest of the week you manage to get a trivial use-case pass. Now, how the hell can you estimate the number of weeks and experiments it will take you to get a realistic problem to run reasonably well? NP-hard problem solving sometimes behaves exponentially but sometimes linearly, you don't always know in advance as it depends on the micro structure of the inputs.
The process of writing software that solves real-world NP-hard problems looks completely stochastic. You can read dozens of papers, try hundreds of different algorithms, approximations, heuristics, technologies and new ideas before you find how to solve the problem at hand, assuming you do. How can you estimate this time - upfront?
On the bright side, NP-hard, decidability and other tough algorithmic problems are only a niche in the world of programming. Most of the time software development is "only" a matter of engineering, planning and experience -- where Scrum could well be the right answer.
I am not a software guy, but an analog microwave design guy. All too often management expectations can in no way jive with reality. Instead it is often necessary to intentionally underestimate times, and later find specific items to pin the "delays" on. Along the way so much money and resources get involved, that effectively you've gotten the project through the second trimester without management realizing they are pregnant. Beatings ensue, but at that point those of us with scarce skills can't be laid off, so we shield our faces and live on to design another day.
Yay, another successful project out the door despite management...
With a building you usually have VERY detailed plans that describe all of the parts that need to be constructed. These parts have physical components that are well defined and involve construction processes that have been around for decades if not centuries. This makes it possible to take advantage of 'construction cost' manuals and programs to come up with accurate estimates.
The process does fall apart when dealing with situations where materials or labor costs soar due to inflation or demand. It may also have problems when dealing with new technologies. And then you may run into the unexpected, like finding that your site survey is wrong and you need deeper foundations to counter the fact that most of your building is on mud and not bedrock.
When you think about it, the civil engineering estimates with detailed costing are done AFTER the design is complete.
When it comes to software, you frequently have to come up with the detailed project definition as part of your estimate. Then you have to guess at how long it will take to design and implement the project definition in an environment that changes quickly. Unlike building construction, many software 'construction' processes have only been around for a handful of years and they may only have a couple of more years of life in them.
To make things worse, the detailed project definition may change as your client gets a look at the prototypes you create. Since redoing software isn't as dramatic as tearing down and redoing part of a building, the end user may think that the new feature is easy to install.
It gets interesting.
Still, there is a section of the McConnell book that is intriguing. It discusses the difference between an estimate and a target. The following is a quote from the book:
"Tip # 2: When you are asked to provide an estimate, determine whether you're supposed to be estimating or figuring out how to hit a target."
Performance testing is unpredictable. Sometimes it is not enough to run a profiler and then just naively tweak the code to get the performance that meets the spec. Sometimes you need to change data structures because you figured out, after integration, that your complex data structure behaves slightly different than during unit testing.
Sometimes you find out that some of your algorithms need to be rewritten. On other occasions, unlike with simulations, your architecture will never work fast enough with the real data your are getting because an inevitable and unpredictable interaction between components. You can't always know these things early enough, you almost never do.
1. Ask the programmers involved how long it will take them to complete their parts. Don't argue with them about the rationale, unless it's clear they're being overly optimistic (in which case, argue for them to increase their estimate).
2. Double or triple their answers (depending on the complexity of the project), because they're undoubtedly still too optimistic about their abilities, lady luck, and the inevitable unforseen.
What you definately DON'T want to do, is to ignore what they say and tell them when you need it. Otherwise, you'll get something like this: Programmers say it'll take 6 months, you want it in three and come up with "rational" arguments about how "it won't take as long as you think" or how it might be done "smarter." If you're lucky, you'll still get it in 6 months and the programmers will feel vindicated instead of guilty.
Try replacing critical sectioning with data locks
In 13 million lines of Mac OS X kernel code. It's mostly an all-or-nothing proposition.
-- Terry
I have to do many estimates, and mine are within 10% error of actual time, then I add 30% on top of that, done.
Today a funny thing happened, I had to switch one implementation of web service call for a totally different one. At 1:16 I said I would be done in half an hour, after changing the build script, build properties, creating the client and switching the implementation in business logic, I sent the message that it was done. Then I looked at the clock, it was 1:46. So I told the other side, that instead of half an hour it took me 30 minutes.
Seriously though, take the task and divide it into smallest chunks that you know can be estimated, this would be close to reality, so add 30%. I can't add more than that, our competitors would get the project then. This method only works for projects that are similar to each other though.
You can't handle the truth.
(Or more precisely multiply by 9/5 and add 32).
This is often enough contingency to handle the curve ball requirements changes that
management and customers will inevitably throw at you throughout the development period.
It may not be enough to cover the gratuitous mid-stream demos that need a week of
diverted-from-productive effort to prepare each time.
And if you have the kind of management that wants to interrupt you for a crisis meeting
or a re-installation of software/OS on their virus infested laptop, or the latest
FAD scrummish trendy management thing at least 3 times per day,
fuggedaboutit. You're completely screwed with any estimate you come up with.
Where are we going and why are we in a handbasket?
Double it and add thirty.
Kind of depends how the targeted release date was arrived at, doesn't it?
If it was arrived at with, say, a dartboard, a roulette wheel, or an arbitrary
time when the runway runs out, and the requirements/feature points/complexity
was not trimmed to suit at the get go, then I don't think it's the team that needs
to be let go. It's whoever set up the untenable situation in the first place.
Where are we going and why are we in a handbasket?
Break everything down into approximately 3 ideal day pieces including unit + system test and adjust to real days using the velocity observed doing similar things in the same environment and you're likely to get close (within a factor of two).
You might get within an order of magnitude (days, weeks, months, years) without the low level design.
A lesser multiplier than order of magnitude generally applies when you haven't done similar things before.
And an even smaller multiplier (2-4) is likely where the environment changed (more customer support overhead, move from offices to cubicles etc.)
Having all the necessary conditions satisfied for accurate estimates can be unlikely in early stage startups.
The only accurate way to estimate it, I'd say.
You can try using historical trends, but you always face the possibility that
the next bug you discover will be akin to an invasion by aliens, madmen, or
unscrupulous bankers i.e. a discontinuity in complexity requiring a 75% refactor
of your whole project. Most times you'll be lucky and won't see this, but
I'm just saying: You can't prove to me it won't happen. It comes from
Rumsfeld's unknown unknowns (the really dangerous unknowns) department.
Where are we going and why are we in a handbasket?
...same as any other feature, with a priority higher than some lower than other features.
Now that's really insightful.
Although I would also add that it is one of the buggier and more unstable features, since it is highly coupled to a large number of other features and bug fixes.
Accurate is easy. Precise is hard. Accurate AND precise is very hard. Accurate, precise and completely within expectations is nigh on unheard of...
Evidence based estimating is what I'd like to see more of and less of the abracadabra 'story points' rubbish that SCRUM practitioners advocated. At a previous organization we went down the SCRUM road and were told to use story points where a story point is a unit of effort (not time) required to do the task. Naturally all the devs were confused and eventually resorted to equating a story point with a unit of time (like an hour) and not a unit of effort as we were supposed to. There's also the problem were one dev's estimate of say 4 story points is not the same as another dev's estimate of 4 story points. There was never a consensus as to what a 'unit of effort' meant unless it was taken to be equivalent to a unit of time. Evidence based estimating seems to provide a better solution since it tracks the history of an individual dev's estimates, recognising the fact that an individuals estimate will differ from another. So for example if someone has a habit of underestimating a task, because of the feedback that goes into the system after the task is done, the system caters for this when that person makes another estimate.
What you should do is ask questions like:
Do I have really intelligent people who are also able and likely to work hard
when they are motivated well to build something new and interesting.
Do my team members take pride in producing excellent and elegant
code? (which includes really good, coherent, useful doc & comments).
Do my team members know how to model domains?
Are my team members fully versed in patterns and re-use and 3rd party
software selection factors.
Do my team members understand that it is essential to look out for red-flag technical
risks, draw immediate attention to them, and actively manage the course of the project
based on the principle of addressing them first.
Are they also all good and smart social interactors? Do they know what
others need to know. Are they friendly, co-operative, good-humoured, and
willing to help each other.
Have I done what it takes to positively motivate this great team?
Is the project new and worthwhile and interesting, and do the developers think
so?
Have I created an environment where it is safe to spend your time helping
others on the team?
Have I given the people private environments where they can think and design
or code for long periods of time uninterrupted?
If you've done all these things, then let them go, and occasionally check in.
You will get software produced as well, and as fast, as you could possibly
hope for. So don't micro manage their work or schedule. Just continually
reassess the questions above, and how well you are continuing to do at
creating an environment for software development success.
You cannot hope to do better than that. If setting up those conditions won't
do it for you, nothing will and you had very unrealistic expectations.
Where are we going and why are we in a handbasket?
Most important step is to train your "customer" about the 4 levels and gain acceptance.
:)
L1 is pre-initiation with virtually no project details. Estimating is done solely by managers using experience, actuals from prior similar work, and their gut feel. We call it the SWAG level, and customer is trained to expect +/- 100%. We also occasionally have to give ROM estimates for our customers to gain funding prior to a project being accepted as real. In this case we use three high-level estimates (worst case, most likely, and best case) and then show three levels of std. deviation to the customer.
L2 is during initiation, when a few more details are known but usually no hard specs. SDLC area leads do the estimates, but still at a high level. Customer is trained to expect +/- 50%
L3 is after business requirements are documented and accepted. SDLC area leads and key staff do the estimates, and chunk work into no more than 80 hour tasks. Customer is trained to expect +/- 25%.
L4 is after technical design is documented and accepted. SDLC area leads and key staff do the estimates, again chunked into >=80 hour tasks. Customer is trained to expect +/- 10%.
Managing requirements changes after L3 is crucial. You have to ensure the customer understands the impact of any changes to scope. Works for us on $15M of project work every year for a happy customer. Side note: after about a year, it's scary how close L1 estimates can be. Managers aren't all bad.
- If we aren't supposed to eat animals, then why are they made out of meat? - Steven Wright
Sums of random variables from distributions with infinite variance may look normally distributed to the naked eye, but nevertheless still have infinite variance.
The trouble is project time length definitely does _not_ come from a well behaved finite variance distribution!
Take 1/3 of your component completion estimates and multiply them by infinity, its a quick way to improve overall accuracy.
I think you underestimate just how much I just dont care.
When ever I am asked for an estimate I pick up some dice and roll them, it does not matter what they say ... add up the numbers and appends weeks ... I will have something working by then. It may or may not be what they wanted.
Funny and true quotes from the parent comment:
"One of the major terms in the non-linear politics is who gets the blame when a product shipped with working functionality proves impossible to extend in the next coding iteration because the wrong foundation was chosen. Do you want the estimate consistent with my professionalism, or with grenades baked in for the next guy to work on this?"
And: "Some day I would love to seal my estimate into a cryptographic vault on the basis that my estimate is only correct if I don't tell anyone. As soon as you tell someone, that person immediately goes around changing the assumed conditions."
. . . which is jolted and horrible and not done professionally so I've never worried about time, but whenever I build anything, or undertake any project whatsoever, what I do is estimate the time to the best of my ability, and then triple it. That usually gets me right on target. ;-)
My sister opened a computer store in Hawaii. She sells C shells by the seashore.
I never found accurate estimates to be all that difficult. I don't subscribe to the extreme/agile/scrum/what ever is the latest process is in the news. Create a design, mock up each page/dialog box whatever. Code one up, write your unit tests. Count up how many database tables you have, code up persistence to one and run your automated tests. Determine how many blocks of logic you will have and code up one and test it. You should have coded up the most difficult part in each category. Then simple math add up each part as though it will take as long as the longest part in each category.. Then as you complete each project, only count completely done parts, don't give partial credit. Recognize that if you estimate four days on a part and two days into it, you are pulled off, you still have four days that have to be made up. Thrashing eliminates all part work not fully completed. Now, if marketing, or your boss or whoever says, you missed this page, your estimate stands only for original design work. New features get new estimates. If you follow this and track your work through two or three projects, you will get better at determining the most difficult parts and learn to code those before you complete your estimate. After doing this for a few years, you will get projects for which you can see the end and you can give better estimates from the hip. But, never promise estimates to be more that +200% -50% accurate. I've had many bonuses tied to finishing on time and I always get my bonuses. Realize that I've architected over five projects with over a million dollar budgets and each took over a year to complete all phases, some multiple years. I also have managed teams from myself to a dozen programmers and support personal (testers, graphic artists, tech writers, etc..). My first project didn't go that well, but after multiple projects I learned how to do it correctly. Don't buy into the comments here that say since so many people do estimating badly, that it is impossible. Also, realize that you will have to read code from the programmers on your team and fire the non-performers. And last of all, ask the programmers on your team for their estimates, but don't use them, use your senior architect's estimates. If a programmer estimates long, there needs to be more training to show them how to code up whatever it is you are writing in the time the architect estimates. If they estimate short they also need training. You must also make sure that sub-tasks are broken down into ½ day to 2 days chunks. If a programmer doesn't finish the first sub-task in time, retrain or re-estimate. You may have a boss that comes in and says, how long will this take, I want the estimate now and I don't want you to do any design or prototyping first. Estimate how long it will take you to find a new boss and add two weeks for notice.
I take however long I think it will take based on previous similar work, and then I double it. If there's free time in the estimate I get to use it to sleep or walk to a coke machine, or do some of the other projects I am getting pushed onto me at the same time.
All those moments will be lost in time, like tears in rain.
For which they traded OPIUM! Tea drinkers are willing to deals thousands of kilos of opium to China in order to get that morning cup. Can coffee drinkers say the same?
All those moments will be lost in time, like tears in rain.
How long it will take depends on whether I am allowed to work on it. I used to be in operations, which meant I fought fires 12 hours a day. Now I am a full time developer, which means I fight fires 12 hours a day, and then spend the rest of my day writing programs. Unfortunately, I am usually too tired from fighting fires to actually do any programming. So if they ask me how long it would take to do something, I tell them "It would take if I am allowed to work on it, however, since I will not be allowed to work on it, it will never get done."
My company also uses a new development approach that I have seen at the last two or three companies that I have worked at, but never seen before in my professional career. That is, instead of having multiple people work on a single project, they have a single person work on multiple projects. We have 7 developers and about 10 times that many active projects. On any given day, the Project Manager for two to three of those projects will be demanding that his project get top priority.
If you are not allowed to question your government then the government has answered your question.
It is to laugh. Developers are never given enough information about what it is they are supposed to deliver. You want a fast sort algorithm? I can do that in, say, less than a week. You want an award winning social networking web site that brings in millions of hits? Might take me, hmmm, a month or two? Maybe more. Oh, please remember to factor in testing and documentation time, people.
Join the window installer's union, where prosperity is a brick throw away!
It can take more, but if it is a full system with design, implementation and delivery, a year is a good rule of thumb.
Projects that include external clients always go slower than internal clients, but not by much. Meetings are delayed, features are dreamed up/changed, and requirements drift ("I meant X not Y -- didn't I say X? [no]"). Sales people want to talk about change management and well defined specs, but those are much more rare than you might think. Of the many many dozens of projects I've worked on, I can safely say only 2 were well spec'd.
I agree with the "estimate and multiply by pi" for the sub components of a full project, but the unspecified, "we want to do something like X" is going to be a long process... never forget the acceptance testing and debugging near the end, and maintenance after it's delivered. Oh ya, holidays. That can get you too.
However, small, well understood projects are easier to estimate and plan. If you've done something before, and it took 2 weeks to implement, it will take 2 weeks to implement -- 1 week to remember WTF you did last time and 1 week to do it again... If you remember WTF you did last time, you probably didn't do enough the first time.
Awesome.
Hofstadter's Law
Anyone who thinks they can predict that which has not been done before, is full of it. If it can be predicted with any accuracy its because it has been done before -- in which case, why are you doing it AGAIN!?
People who can give schedules are people who are pulling the wool over management's eye. But software isn't like manufacturing, where you take known parts, and known formula and combine them in a known way to get a the same result as you got last week. It's doing something that hasn't been done before. How people think they can accurately predict that is beyond me. You have to do the project to know how long it's really going to take.
The closer you get to the end, the more accurate your estimates may get. OR not, if you succumb to some 90/10
rule.
But it's not what was asked for.
SLOC is a useless metric of productivity - and measuring productivity isn't even the objective here. It's to budget and plan a project. Since the cost of most things involved depends on time (staff are paid by the day) and time is a what's used to coordinate activites (we'll have the system up on 1 March - make sure the users are available), producing an answer in units of SLOC is about as useful as one in feet or ounces.
You say they subject you to mockery. Really?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Joel Spolsky has written about making useful estimates at http://www.joelonsoftware.com/items/2007/10/26.html
The short version: for each developer, gather their estimated times and actual times for each of their projects.
If the ratio between the two is always 1, that person is the perfect estimator. If it's systematically close to some x != 1, you just divide all their estimates by x to compensate for their optimism (or pessimism, as the case may be). If the estimate factors are all over the board, you teach them how to estimate times better.
That sounds almost exactly like what Joel Spolsky talked about ("Evidence Based Scheduling") in his article at http://www.joelonsoftware.com/items/2007/10/26.html
Cups of Coffee. I mean Pitchers of coffee
I though the idea was to estimate in units after complexity. Units can be gummy bears or whatnot, but not bound to time in any way.
The reason being that it is much easier to relate to complexity than factor in everything to get a correct time estimate. Complexity can also be agreed upon by different people, even though the time required for them to complete an equally complex task can be very different for different developers, depending on skill or amount of disturbances from programming time.
Estimate a task in complexity. Multiply with a factor to get the time estimate. The factor depends on the developer, complexity depends on the task. Keep them separate.
I lost my sig.
It's always an inaccurate science, but since the consulting business seems to be hopelessly dependent on it, here are my best suggestions:
1. Try to break down tasks into the smallest measurable subtask. It's easier to estimate "form for adding new users" than it is to estimate "create the admin site"
2. It's going to take longer than you think, so plan more time than you think you need.
3. If possible, try to add generic "risk hours" to each project, for unexpected issues. This isn't always possible, but it's a great help.
And, finally, the most important one:
4. Beware of timecreeps. This is related to the first tip. If your planning is detailed enough, you can usually say "Oh, you want the create-user form to be submitted by using ajax? Sure, no problem. That would take around 2 more hours. Any problem there?". With a less detailed specification, the customer is more likely to assume it's a part of the original estimation.
Important stuff
For any large project read this Black swan theory. Something completely unexpected will probably ruin your plan, as others have said it's more about knowing what to chop to hit a date. Also for any large project the cumulative effect of errors in estimating soon add up to make the plan almost irrelevant.
Check it out: http://www.gosu.pl/woorky/
The typical practice I've seen and used is cost modeling based on similar projects in the past.
One company I worked for used parametric modeling with SEER-SEM. That was the most reliable, accurate, and precise method I've ever seen.
- Cardhu
My formula:
Te * 2 + n
Where Te is the time I think it takes after reading the specifications, and n is the "nose factor". Usually works pretty well.
If a train station is a place where a train stops, what's a workstation?
It doesn't matter what you say. They will increase the feature set and move up the deadline anyway. Usually its best to find out what they want to hear and just tell them something close to that, because that is all they will hear anyway.
I know nothing about the Mac OS X kernel, but I don't understand why such a transition couldn't be done in pieces -- the code is modular, isn't it?
I know nothing about the Mac OS X kernel, but I don't understand why such a transition couldn't be done in pieces -- the code is modular, isn't it?
:-)
I do not think you know the meaning of the word monolithic.
I do not think you know the meaning of the word monolithic.
Being monolithic is one thing, being composed of logically distinct modules is another.
1. Ask all the programmers and customers SEPARATELY how long they estimate.
2. Take the HIGHEST estimate
3. Multiply by 2.2
Over 50 projects I was never out by more than 8%...
Dunno why it works.
Try replacing critical sectioning with data locks
In 13 million lines of Mac OS X kernel code. It's mostly an all-or-nothing proposition.
-- Terry
No, it's not. A major chunk of the code is in drivers. Thus, you could first push a version out of the door that only supports XServe (rack mounted servers) or Apple TV. That's dividing and thus lowering risks.
8 of 13 people found this answer helpful. Did you?
A good (experienced) programmer should eventually have a good 'feel' for how much time certain tasks take (but having domain knowledge does help too), and the scrum planning poker is a way to get to such an estimate, but it is of course not perfect. Very important is a proper brake down of the tasks (not forgetting any tasks). Many developers under estimate the time it takes to write some code and provide proper unit tests for the test team, this results sometimes in going to the other extreme and estimating too much time. Another approach is to look at historical data of your developers. This guy wrote a case study that uses historical data of his developers to estimate future tasks : http://vanlingen.name/web/cv/unpublished/article/2010/02metrics/metrics.pdf It is an interesting approach, but I would not only rely on that. A combination of techniques: historical data, estimation by developers, good task breakdown (not forgetting tasks), I think is needed for estimating the time it takes to complete a project.
Maybe we could write an article together about this subject.
Why is this modded down? GP talks crap and deserved to be shot down.