Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When giving a time estimate for a project that includes work in areas you don't have experience with how do you estimate?
In most cases it is hard enough to get the estimate right when the project's areas are familiar.
What methods have you used in these cases? How well did they work?
Not Serious...
Reach your hand up in the air.
Grab an estimate.
Write down what you find.
Ok, ok...
It's hard. Actually, it is not possible to give an accurate estimate of something that is not known. But that doesn't stop people from needing to know.
Write down a list of all functional components or aspects that you are aware of.
Be as vague as necessary to cover everything.
Now, you have a list of components. For each component, do your best to get the business and/or functional requirements of that part. Why is it there? What is it supposed to do? Why? How? Drill down to more detail, add as many items to your list as possible (nested, components, sub-components).
The more items you have the easier it is to estimate each one.
Then double it!
I think it is very reasonable to walk the stakeholders through some level of design in order to provide an estimate. Otherwise, it's like walking up to a construction company and saying "I want a house, how much will it cost?"
And keep in mind -- it is an estimate :)
Oh, one last thing... Be clear about what it is that you are estimating. If it is "a, b, c" and they later ask for "d", it will be easy to point out that your estimate did not cover "d"... your new estimate is ...
Know what you Know AND Know what you don't Know and you'll be successful.
Use a work breakdown structure (WBS) to get the sub parts of the project/application/whatever. You can provide an est. (to a degree) of the effort to get the knowns complete, as with any project there are the unknowns - identifying them is the first big step. The best next step is to add to the WBS steps to better know those unknowns, for example, if the task is to go BBQ a cheese burger with strips of bacon and you've never BBQ'd bacon before - then you break the job down to getting the ingredients, getting the BBQ, starting the BBQ, etc. and the one thing you don't know - getting/cooking bacon you add some sub-components like:
call butcher
research bacon cooking
hire bacon BBQ'er expert
etc. - each of those you can assign some est. to and put a ? near the actual cooking. Call it a proof of concept (can you bbq bacon?), research and development, whatever - but there are somethings when you start a project you don't know, but you can devise a plan to better know those areas AND once you do revisit the plan and add the findings. By doing this you're communicating out to the team, sponsors, etc. what you know, those areas you don't know but have a plan to get to know, and a rough est. with the unknowns identified.
MinMaxLikely is the method I use. The minimum for the case where everything goes well, the maximum for everything going pear-shaped, and the likely somewhere in between.
Of course, management only ever looks at the minimum figure but, by the time they start complaining about cost over-runs and missed deliverables, you've already got them locked in and you have been (hopefully) keeping the fully appraised of any problems you've encountered and the effect those problems are having (pushing the actuals away from Min and closer to Max).
Have you tried planning poker?
These SO questions might be relevant:
How to estimate the length of a programming task
Dealing with awful estimates
The most significant project management mistakes
Do you practice the planning game?
You cannot estimate these, you can only guess. The difference, to me, is that an estimate is based on knowledge & experience, and you have neither for the unknown.
You have to constantly reevaluate where you started, where you stand, and your guess on what's left. You could probably break down your problem into steps but your biggest issue will be in the "footnotes" of what you're learning.
The example that comes to mind was my first C# interop with Word. It was entirely unknown and I didn't have the foggiest clue what it would take to generate a 1000 page formatted document based on database information. It, in itself, is pretty straight-forward: open Word, format page, and insert data. There are all kinds of issues that cropped up that you couldn't fathom and that easily doubles your guess.
Ask people who are familar with the concepts how long it would have taken them back when they first learnt the technique (including how long to learn). Average the results and adjust based on your capability to learn.
Then guess anyway and triple the quote. Doubling is for chumps.
Wherever possible, go one meta-level up: give an estimate of when you can give reasonably accurate estimate.
"I don't know enough about Foo to give an accurate estimate, but I will know enough about Foo by Thursday week."
I acknowledge it often isn't possible, but I try to make it an option when I am project managing.
You can even go up another meta-level, in large projects.
"I don't know how long it will take for us to get a expert in to give us an estimate. I will talk with my colleagues, and give you an estimate on Friday of how long it will take to get an expert estimate."
This can be combined with large error margins, diminishing rapidly. "It will take 1 year, +/- 9 months. I'll give you another estimate with an error range +/- 3 months by June 30."
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What I mean is if I am breaking a programming project estimate down into tasks as much as possible would there be a good maximum to make the tasks. Meaning if I say the max is 4-6 then if any task is more hours than that it needs to be broken down into more tasks. I feel like there is a point where this becomes not much more useful though and think that a max of 10-12 hours is acceptable, the boss does not agree. The idea here is to be able to know as well as possible how much time is needed to complete the task but at the same time I think there is a point where too much breakdown is meaningless until you actually dive into the code. Any thoughts or common practice?
Make the breakdown structure detailed enough to allow you make a proper estimation, but not too detailed so you'll have trouble maintaining and tracking it later, when things change (not if things change, but when things change).
It doesn't really matter the number of hours a task in WBS is estimated.
When I was writing my own time breakdowns for a task, I found the most useful number to go with as a goal for a single task to be max'd at about 4 hours. Then, if it turned out to be really difficult and take a lot longer than I expected, it wasn't so terrible.
I don't think it is useful to actually hold any of these projects as meaningful unless:
1.) The person performing the task created the projection.
2.) The person creating the projection is familiar enough with the work.
At my last job, I didn't even start projecting tasks until I had been there for three months. After that, it was another month or two before my projections were meaningful.
I think that this is a very individual thing. If you are used to thinking about things at an extremely detailed level, it makes more sense to have lots of small tasks. If you like to think of things in more general terms, it makes sense to have a few big tasks. I believe if you and your boss try and enforce this sort of personal preference into task projection, you will find that your projections are meaningless at best and a creator of hostility at worst.
I hope my experiences and expression of them is useful to you.
-Brian J. Stinar-
What does a task look like?
write a document? Write a chapter of document? Write a sentence in a document?
Write a programme? Write a class? Write a method?
I think the following need to be true:
1). A task is big enough so that you know you've finished it. A single sentence or method doesn't stand alone. You typically can't deliver something that small in isolation, the receiver can't "test" it.
So, for example, you can unit test, document and check some code into an SCM that's a task.
I can't imagine tasks smaller than one hour, and typically for me they are half-days.
2). A task is small enough that you can be confident you can do it in the estimated time. You've analysed the problem well enough to understand the chunks.
People are not machines.
Having that said, the way I see it there are two main development modes:
develop
Maintain/fix
For the second one you can gain experience on how long tasks should take - the developer knows the code and most of the times he can give a good prediction what is wrong and what should be done to make it work (in that case tight monitoring + buffer to keep getting good cooperation is in order, if the developer can't get a good estimation - that is an indication of a very big problem)
For the first one - it's more complicated:
if this is hard labor job - one that requires no brain and just take the program from point a to point b than... you can define tight schedule.
If you need the developer to get creative, to think about good implementation etc... You can not wait forever for a masterpiece, yet you will not get much from a developer that have only survival thoughts :)
Learn about Agile -where the team leaders and the developers sets the goals together- the goals may be very demanding but within the development period the developer which feels as responsible as the manager... can manage his time.
So sometimes, with the correct management system - tasks can and perhaps should be a week long.
There is no magic number. Understand your type of programing and find an appropriate management management system.
Good luck
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
As a lead developer I often get handed specifications for a new project, and get asked how long it'll take to complete the programming side of the work involved, in terms of hours.
I was just wondering how other developers calculate these times accurately?
Thanks!
Oh and I hope this isn't considered as a argumentitive question, I'm just interested in finding the best technique!
Estimation is often considered a black art, but it's actually much more manageable than people think.
At Inntec, we do contract software development, most if which involves working against a fixed cost. If our estimates were constantly way off, we would be out of business in no time.
But we've been in business for 15 years and we're profitable, so clearly this whole estimation thing is solvable.
Getting Started
Most people who insist that estimation is impossible are making wild guesses. That can work sporadically for the smallest projects, but it definitely does not scale. To get consistent accuracy, you need a systematic approach.
Years ago, my mentor told me what worked for him. It's a lot like Joel Spolsky's old estimation method, which you can read about here: Joel on Estimation. This is a simple, low-tech approach, and it works great for small teams. It may break down or require modification for larger teams, where communication and process overhead start to take up a significant percent of each developer's time.
In a nutshell, I use a spreadsheet to break the project down into small (less than 8 hour) chunks, taking into account everything from testing to communication to documentation. At the end I add in a 20% multiplier for unexpected items and bugs (which we have to fix for free for 30 days).
It is very hard to hold someone to an estimate that they had no part in devising. Some people like to have the whole team estimate each item and go with the highest number. I would say that at the very least, you should make pessimistic estimates and give your team a chance to speak up if they think you're off.
Learning and Improving
You need feedback to improve. That means tracking the actual hours you spend so that you can make a comparison and tune your estimation sense.
Right now at Inntec, before we start work on a big project, the spreadsheet line items become sticky notes on our kanban board, and the project manager tracks progress on them every day. Any time we go over or have an item we didn't consider, that goes up as a tiny red sticky, and it also goes into our burn-down report. Those two tools together provide invaluable feedback to the whole team.
Here's a pic of a typical kanban board, about halfway through a small project.
You might not be able to read the column headers, but they say Backlog, Brian, Keith, and Done. The backlog is broken down by groups (admin area, etc), and the developers have a column that shows the item(s) they're working on.
If you could look closely, all those notes have the estimated number of hours on them, and the ones in my column, if you were to add them up, should equal around 8, since that's how many hours are in my work day. It's unusual to have four in one day. Keith's column is empty, so he was probably out on this day.
If you have no idea what I'm talking about re: stand-up meetings, scrum, burn-down reports, etc then take a look at the scrum methodology. We don't follow it to the letter, but it has some great ideas not only for doing estimations, but for learning how to predict when your project will ship as new work is added and estimates are missed or met or exceeded (it does happen). You can look at this awesome tool called a burn-down report and say: we can indeed ship in one month, and let's look at our burn-down report to decide which features we're cutting.
FogBugz has something called Evidence-Based Scheduling which might be an easier, more automated way of getting the benefits I described above. Right now I am trying it out on a small project that starts in a few weeks. It has a built-in burn down report and it adapts to your scheduling inaccuracies, so that could be quite powerful.
Update: Just a quick note. A few years have passed, but so far I think everything in this post still holds up today. I updated it to use the word kanban, since the image above is actually a kanban board.
There is no general technique. You will have to rely on your (and your developers') experience. You will have to take into account all the environment and development process variables as well. And even if cope with this, there is a big chance you will miss something out.
I do not see any point in estimating the programming times only. The development process is so interconnected, that estimation of one side of it along won't produce any valuable result. The whole thing should be estimated, including programming, testing, deploying, developing architecture, writing doc (tech docs and user manual), creating and managing tickets in an issue tracker, meetings, vacations, sick leaves (sometime it is batter to wait for the guy, then assigning task to another one), planning sessions, coffee breaks.
Here is an example: it takes only 3 minutes for the egg to become roasted once you drop it on the frying pen. But if you say that it takes 3 minutes to make a fried egg, you are wrong. You missed out:
taking the frying pen (do you have one ready? Do you have to go and by one? Do you have to wait in the queue for this frying pen?)
making the fire (do you have an oven? will you have to get logs to build a fireplace?)
getting the oil (have any? have to buy some?)
getting an egg
frying it
serving it to the plate (have any ready? clean? wash it? buy it? wait for the dishwasher to finish?)
cleaning up after cooking (you won't the dirty frying pen, will you?)
Here is a good starting book on project estimation:
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
It has a good description on several estimation techniques. It get get you up in couple of hours of reading.
Good estimation comes with experience, or sometimes not at all.
At my current job, my 2 co-workers (that apparently had a lot more experience than me) usually underestimated times by 8 (yes, EIGHT) times. I, OTOH, have only once in the last 18 months gone over an original estimate.
Why does it happen? Neither of them, appeared to not actually know what they are doing, codewise, so they were literally thumb sucking.
Bottom line:
Never underestimate, it is much safer to overestimate. Given the latter you can always 'speed up' development, if needed. If you are already on a tight time-line, there is not much you can do.
If you're using FogBugz, then its Evidence Based Scheduling makes estimating a completion date very easy.
You may not be, but perhaps you could apply the principles of EBS to come up with an estimation.
This is probably one of the big misteries in the IT business. Countless failed software projects have shown that there is no perfect solution to this yet, but the closest thing to solving this I have found so far is to use the adaptive estimation mechanism built in to FogBugz.
Basically you are breaking your milestones into small tasks and guess how long it will take you to complete them. No task should be longer than about 8 hours. Then you enter all these tasks as planned features into Fogbugz. When completing the tasks, you track your time with FogBugz.
Fogbugz then evaluates your past estimates and actual time comsumption and uses that information to predict a window (with probabilities) in which you will have fulfilled your next few milestones.
Overestimation is rather better than underestimation. That's because we don't know the "unknown" and (in most cases) specifications do change during the software development lifecycle.
In my experience, we use iterative steps (just like in Agile Methodologies) to determine our timeline. We break down projects into components and overestimate on those components. The sum of these estimations used and add extra time for regression testing and deployment, and all the good work....
I think that you have to go back from your past projects, and learn from those mistakes to see how you can estimate wisely.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I know this may not be exactly a coder question, but I feel it is still related to programming because I'm sure many developers have come across this before and might have some insight on how to resolve this or have advice. There is an actually programming question though.
My issue as a developer.
I work in a small company, roughly 15 people, 5 of which are developers include myself, the rest are tech support and management. Problem I'm having is, when we get a SOW (Statement of Work), our clients give us a rough description of the project they are requesting, which usually is a 1-3 page brief description, usually including a Visio document, now as a programming, I'm responsible for going over the document and relaying a time-line on how long it should take me to complete the project.
Unfortunately, there have been times, not only me, where we under-estimate the project because we didn't fully get into it till we actually developed it, which ends up slapping ourselves in the face, because my boss is upset because he is being hounded by the client, who is now upset because we missed our promised deadline.
My question is, how do you guys handle organizing basic project description when you need to give deadlines on more concept, and do you have any ideas on how to organize it.
I'm thinking of going to my boss and suggesting, instead of always pushing a estimated deadline to our clients which expect us to hit that, we should write up a detailed document that is more step-by-step (more like what to do) on how to develop the application they want, it may take a lot more time, but least if the project is moved to someone else it is laid out for them, and when I usually get back to it 4 months later, I don't have to refresh up again, I can just follow the steps I wrote.
What do you guys think? Ideas? Or better ways to handle this?
If you switch your development to using an iterative methodology (Agile, XP, Scrum, etc), then the customer will see results much earlier than any deadline you feel you have to promise - usually every 1 or 2 weeks.
The moment they see what you've developed, I can pretty much guarantee that they'll make changes to their initial requirements as they now have a visual representation of the product and it may not be quite what they were thinking of. Some of their changes might be quite radical, so best to get the feedback as early as possible.
In all the projects where i've insisted we do this, the customer was delighted - they saw the results early, could influence the project outcome, and we hit their end deadline. Unexpectedly, a whole load of features got left behind and - guess what - the customer did not mind at all as they got the top features they wanted and put the project/product straight into production as they'd had lots of time to refine it to suit their business, so they were already familiar with it.
It takes a lot of effort to get management, sales, creative, etc, to all buy-in to an iterative style, so you may need to implement a hybrid solution int he mean time, but in my experience, it is well worth it.
If a complete shift to iterative is not possible, split your project into tangible milestones and deliver on those milestones. As others have said, inflate your estimates. My previous manager doubled my estimates and the sales team doubled his too.
Inflate your project deadlines. It's something that most programmers should do (and I quote the VP of Freeverse, the company that I work at):
It is a well-known fact among people
who work in the software industry that
the last 5% of development always takes the longest.
If possible try to divide the higher level tasks as much as possible so that you can get a better approximation of how many man hours that sub-task would take.
Also, adding hidden buffers to your task execution helps in covering some of the unseen contingencies.
cheers
If you mock up (balsamiq or whatever) with your customer, you will get more details. Armed with those details and some experience, your estimates will be more accurate. And then double it and add 4 (hours,days,weeks,months)
First, unless you systematically under-estimate, your boss should not get upset. It's his job to answer to the client, and he should know that by definition, an estimate is NOT the future. Statistically, sometimes you should deliver earlier, sometimes later.
Personally, I think that the frame of "how long will it take" is not exactly the right discussion to have. Software development is a risky business, and change/surprises happen all the time. One approach which helps is to focus less on the "right" number, and more on the volatility. Look at the project, and consider the places where you are pretty clear on how long it will take (you have done it before and understand it well), and look at the places where you have uncertainty (unclear requirements, new technology), and for these, think about how bad it could go, and why. That will help you get not one number, but rather boundaries: what you think is reasonable, a worst-case scenario, maybe a best case scenario (which the client should never see :) ) - and convey that information to your boss, so that he can manage accordingly.
Additionally, this will allow you to identify the danger points of the project, and you can then prototype accordingly - look into the uncertainty points as early as possible, so that you can tighten up the timeline fast, and have early warnings for your boss and the client.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
As a new developer who is the only software guy on staff I have faced a few challenges but possibly the most difficult has been time estimates. I strugle every time I have to give a project estimate.
My question then is; If I do not have any experience and I don't have a fellow dev in my environment, how do I provide a solid estimate? I have read Joel Spolsky's article on Evidence Based Scheduling but how can that apply if I do not have any evidence?
I appreciate any advice on this subject.
You don't provide a solid estimate. You give as good an answer as you can, and explain that it is just a very rough estimate, and why it's so rough.
If you make it very clear that:
You can't give an accurate estimate
It's entirely reasonable that you can't give an accurate estimate because it's different work to what you've done before
You'll update the estimate as time goes on and you get to know the topic better
I think you should be okay. You need to make those things very clear though, in writing, so that you don't get held to your rough estimates later.
You are allowed to say "I don't know, I don't have enough evidence"
Then do some prototyping to get some evidence.
Then answer the question.
So you may in fact be able to give an estimate of when you will be able to give the estimate.
IMO Joel is way, way off in his article, and his conclusions and recommendations are not based on any reality. (Sorry, Joel) Fundamentally he says that you should be able to schedule your work down to units of time of hours or less before you even begin. But the reality is you don't know what those units of work are all going to be (in non-trivial systems) before you get in to the code. So you can't come up with an hour-by-hour breakdown of what you're going to do before you even pop the hood and have that breakdown reflect what actually happens with any accuracy.
Giving a project estimate is very difficult if you want that estimate to be of any value. Coming up with accurate estimates is difficult for programmers because very often you don't discover all the complexities of the project until you get under the hood.
So the solution to this is to get under the hood when coming up with estimates. For smaller projects & bug fixes this is fairly straightforward:
Replicate the bug on your machine.
Find the code that is causing the bug.
Figure out how to write the code that will fix the bug.
Estimate how long it will take you to write that code.
In finding the code you have to write you necessarily must discover most or all the complexities that would have thrown off your estimate.
The interesting thing about this method is that the time it takes to generate the estimate is very often 90% of the total time to actually do the work. You practically have to do the work in order to come up with an estimate. With bug fixes especially, the solution is often on the order of one line of code, so your estimate will end up being 5 minutes. That's fine because deadlines can be set around estimates like that.
As you get practice with this you will get better and better at "just knowing" how long things will take. At first you'll only be able to "just know" how long the smallest projects will take. But over time you will be able to estimate larger & larger projects.
I first base my estimate on my percieved complexity of the problem. How big is the problem. How many pieces might it touch or require. This gives me a general guideline. Then I always make sure I add a 15-25% fudge factor because you are going to miss something.
Finally you make it very clear that this is a rough estimate based on your understanding of the problem, and how you might solve it.
Also do not give any rough estimates in very precise increments. 4.5 hours is not a rough estimate. Half a day is a rough estimate.
Although it is very rough, I estimate on Lines of Code. This parameter, whose meaning for productivity is close to zero, still gives you an idea of the complexity of a project.
Measure the fact that on average, a developer can write circa 200, max 300 lines of code per day. Keep into account that just for coding of a single man army:
A small project of 1000 lines of (logic) code can be done in one or two weeks
An average complexity project of 10.000 lines of (logic) code could be completed in two or three months.
A large project of 100.000 lines of (logic) code requires at least a couple of years
To the logic code, you have to add the testing, which is already included in the previous estimates. To have a clue of the complexity, the Gimp is 600.000 lines of code, a kernel ranges in the million or more.
To this, add the fact that if you are working waterfall, the time you need to develop the code is actually a small part of the time needed to develop specifications and design. I would estimate a 2/3 time is for specs+design, and the remaining 1/3 goes in coding, maybe even more on the specs+design part. It is really time consuming.
So, track your estimate from the complexity, to the lines of code, consider the manpower you have and how much they can work in parallel, and add the overhead of specs+design, you will get a very rough estimate.
I suggest you the mythical man month. It is a fantastic book on this regard.
Personally, I imagine an estimate as a statistical distribution - and try to communicate the idea of standard deviation with it:
10 is 'it has a 50% chance to be between 8 and 12'
It's hard to get much more precise than that for overall project estimates. It is perfectly possible to get more precise (split into individual independent stories, collectively estimate each, and other agile practices) - but it has a cost.
(Also, an estimate should NOT be an engagement on deliverables - otherwise it gets padded to death and becomes useless)
If you refuse to give an estimate for something you have never done, you will probably do that all your life. First split the task as much as possible, this will help you clarify how you are going to do it. There is more chances you will be able to compare a fragment of the task with something you have done before. Don't hesitate to communicate your degree of certitude to your manager.
For an experienced programmer, who at least knows the system and has a set of reasonable requirements in front of them, "i don't know" is not a valid answer. If you say you don't know your PHB will go off and apply their 1337 h4x0r sk1lz and make an estimate in the order of "that sounds like a piece of cake, how about 1 hour".
You should be able to break the problem down into a series of smaller problems you've solved before and come up with a reasonable number for each part. Point out that it is very rough and could blow out considerably once you get to full analysis of the problem.
They're called 'estimates' because they're rough. You get better at estimating by doing it more and learning to draw on past experience as much as possible. Remember to factor in contingency (interruptions, task switching, possibility of being sick, possible rework, etc). Usually adding 50% makes the estimate closer to the mark.
Provide a rough estimate and be really clear about that.
Identify a strategy on how you will tackle the project. Particularly identify pieces of the system you can deliver as working intermediate releases. Pay special attention at the closest of these you would be able to release fully functional, and if possible take the rest out of scope (keep a list of these and anything that comes up, to be scheduled as a follow up project).
Use short iterations. Consider/analyze how the intermediate releases fit in 2-6 week iterations. Take into account learnings this give you, and adjust the overall estimate.
Go on with the first iteration, and apply what you learn about the assumptions you made. How off you are in the early iterations usually point to a problem in the estimates. Resist the temptation of considering the deviation in the estimates part of the initial overhead, as you will probably be delaying the point in time where you realize the estimates where off. Note that I do understand/agree the velocity of the project increases over time, but thinking about that tends to hide/delay the issues.
I do this all the time. ALmost everything I do is the first time. How do I estimate ? I guess! And then I guess again. And I keep doing that each delta-time interval that a schedule is reworked, because project plans are iterative and you only what you know when you are doing it. My guesses are pretty good tho because I have, after many many years, figured out what 'looks' easy and what 'looks hard'
Try Function Point Analysis. For CRUD stuff it gives good ballpark figures. It's main advantage is that it's based not on what you are going to implement, but on what the user has asked for. You'll need to find out what your FP productivity is, though. You can use past projects in the same language to do that.
You could use average productivity for the target language if you just can't build a historical dataset. It will give you something, not necessarily approaching reality, but will at least let you compare efforts for different projects.
Now, mind you FPA is bad on algorithmically-heavy software, and it relies on AVERAGES, meaning you'll probably overestimate or underestimate each project.
my coworker always says, first estimate the project length, then multiply it by two add 1 and then add the next highest units. so if your answer is 3 days, then you would say 7 weeks. that's a half joke, one idea would be first estimate the project and then when its finished see how far off you were, maybe you are consistently off by a multiple of 2 or 3, or whatever.
Any unknown task or job always has something which is known to a certain degree and easy to estimate. I split and I give estimates right away for the things I know and for the things I feel I know. The rest is honestly being declared as a thin spot and then we start "bargain". If work giver trusts my competence he will except my rough estimations and risks - we work together. It was never a failure, simply because I would never take a task which I can't lift or run into the ground (gut feeling?). If work giver doesn't trust me, I always recommend who to ask and where to look for a better option. Then we either work together or not. Most of the time we do, but everyone is on the safe side. I do my job, "thin spot specialist" gets his/her cut, managers are happy and customer's satisfied. Perhaps it's a bit naive, but it works for me :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I mean name off a programming project you did and how long it took, please. The boss has never complained but I sometimes feel like things take too long. But this could be because I am impatient as well. Let me know your experiences for comparison.
I've also noticed that things always seem to take longer, sometimes much longer, than originally planned. I don't know why we don't start planning for it but then I think that maybe it's for motivational purposes.
Ryan
It is best to simply time yourself, record your estimates and determine the average percent you're off. Given that, as long as you are consistent, you can appropriately estimate actual times based on when you believed you'd get it done. It's not simply to determine how bad you are at estimating, but rather to take into account the regularity of inevitable distractions (both personal and boss/client-based).
This is based on Joel Spolsky's Evidence Based Scheduling, essential reading, as he explains that the primary other important aspect is breaking your tasks down into bite-sized (16-hour max) tasks, estimating and adding those together to arrive at your final project total.
Gut-based estimates come with experience but you really need to detail out the tasks involved to get something reasonable.
If you have a spec or at least some constraints, you can start creating tasks (design users page, design tags page, implement users page, implement tags page, write tags query, ...).
Once you do this, add it up and double it. If you are going to have to coordinate with others, triple it.
Record your actual time in detail as you go so you can evaluate how accurate you were when the project is complete and hone your estimating skills.
I completely agree with the previous posters... don't forget your team's workload also. Just because you estimated a project would take 3 months, it doesn't mean it'll be done anywhere near that.
I work on a smaller team (5 devs, 1 lead), many of us work on several projects at a time - some big, some small. Depending on the priority of the project, the whims of management and the availability of other teams (if needed), work on a project gets interspersed amongst the others.
So, yes, 3 months worth of work may be dead on, but it might be 3 months worth of work over a 6 month period.
I've done projects between 1 - 6 months on my own, and I always tend to double or quadrouple my original estimates.
It's effectively impossible to compare two programming projects, as there are too many factors that mean that the metrics from only aren't applicable to another (e.g., specific technologies used, prior experience of the developers, shifting requirements). Unless you are stamping out another system that is almost identical to one you've built previously, your estimates are going to have a low probability of being accurate.
A caveat is when you're building the next revision of an existing system with the same team; the specific experience gained does improve the ability to estimate the next batch of work.
I've seen too many attempts at estimation methodology, and none have worked. They may have a pseudo-scientific allure, but they just don't work in practice.
The only meaningful answer is the relatively short iteration, as advocated by agile advocates: choose a scope of work that can be executed within a short timeframe, deliver it, and then go for the next round. Budgets are then allocated on a short-term basis, with the stakeholders able to evaluate whether their money is being effectively spent. If it's taking too long to get anywhere, they can ditch the project.
Hofstadter's Law:
'It always takes longer than you expect, even when you take Hofstadter's Law into account.'
I believe this is because:
Work expands to fill the time available to do it. No matter how ruthless you are cutting unnecessary features, you would have been more brutal if the deadlines were even tighter.
Unexpected problems occur during the project.
In any case, it's really misleading to compare anecdotes, partly because people have selective memories. If I tell you it once took me two hours to write a fully-optimised quicksort, then maybe I'm forgetting the fact that I knew I'd have that task a week in advance, and had been thinking over ideas. Maybe I'm forgetting that there was a bug in it that I spent another two hours fixing a week later.
I'm almost certainly leaving out all the non-programming work that goes on: meetings, architecture design, consulting others who are stuck on something I happen to know about, admin. So it's unfair on yourself to think of a rate of work that seems plausible in terms of "sitting there coding", and expect that to be sustained all the time. This is the source of a lot of feelings after the fact that you "should have been quicker".
I do projects from 2 weeks to 1 year. Generally my estimates are quite good, a posteriori. At the beginning of the project, though, I generally get bashed because my estimates are considered too large.
This is because I consider a lot of things that people forget:
Time for bug fixing
Time for deployments
Time for management/meetings/interaction
Time to allow requirement owners to change their mind
etc
The trick is to use evidence based scheduling (see Joel on Software).
Thing is, if you plan for a little extra time, you will use it to improve the code base if no problems arise. If problems arise, you are still within the estimates.
I believe Joel has wrote an article on this: What you can do, is ask each developer on team to lay out his task in detail (what are all the steps that need to be done) and ask them to estimate time needed for each step. Later, when project is done, compare the real time to estimated time, and you'll get the bias for each developer. When a new project is started, ask them to evaluate the time again, and multiply that with bias of each developer to get the values close to what's really expects.
After a few projects, you should have very good estimates.