Slashdot Mirror
How can a Developer Estimate Times?
SubliminalVortex wonders: "Many times in the past, I have been asked on 'how long' it would take to implement a certain features/fixes in a product. What's interesting is that many times, certain 'fixes' is adjusting the wording/placement of the items in question; in other cases, users want the product to do everything they ever imagined, since it already started by following their line of thought. From there, the problem continues. From the user interface, people 'imagine' and think that 'oh, it would be easy if...' and scenarios occur, not only internally from the company using the product, but the clients themselves. Usually, several good ideas are there, but estimating times is a pain in the arse if you have a platform you're writing code for which has no documentation. How do coders estimate times to their bosses? If I know the answer outright, I'll give it, but in some cases, I don't how much time I'll take from other developers *because of the lack of documentation*. I'm going to have to bring in my D&D dice next week just to start."
The only way to tell is to design the feature, then guesstimate how long each part of the process will take (by comparing it to how long similar problems have taken). If there's a step you're unsure of, you need to be sure of it to give a reliable estimate. Then double it- something will go wrong, and its better to deliver early than late.
I still have more fans than freaks. WTF is wrong with you people?
Nature disguises weak products as Beta
http://lazybastard.ehuna.org/archives/000032.html
I take guesses, try to schedule a bunch of things sequentially, multiply everything by 2.5, and then wheedle the features out of the release in a series of drawn-out arguments with the users. I tend to miss individual goals, but overall everything works out.
Also, I stopped worrying about being right. By the time people worry about it, it's typically too late to do anything useful to fix it anyway.
With your situation, all I can figure is that it'll get better over time, as you gain familiarity with the system. Estimating is always largely guesswork, and only information leads to good guesses.
Slashdot - where whining about luck is the new way to make the world you want.
The Estimator's Rule:
It always takes longer than estimated, even after accounting for the Estimator's Rule.
With the Scrum development process, the requesting parties are able to get feedback every 24 hours. The development team's does not commit to delivering more than they believe can be achieved in thirty days. See if you can get your bosses to buy in. Here's a website: http://www.controlchaos.com/about/
...use a random number generator? :)
More seriously, I've found from past exeperience you should always take whatever time you think the project will take and multiply that number by 2 or 3. If you are lucky (and the customer requirements don't change to much) you should make it.
Two things really... you have to break your tasks down into small tasks with known dependencies to the point you *can* estimate times to do things. Once you get that far, experience (gut feeling) will contribute. After that, you give an optimistic and pessimisitic times to your boss. Example: If all these assumptions hold and these other three things happen on time, then the time estimate is one week. If this, this, or this doesn't pan out as expected, then the time estimate is three weeks.
I'm more of a web developer, so I don't have to mess with the annoyances of C++, C#, VB.NET, java, etc. 'Fixes' to me, are usually adding yet another CSS and/or JavaScript hack to make IE view a site correctly. And since I primarily use Ruby on Rails or PHP for my coding, the most annoying part is the god damned SQL code! So usually, I base the time 'fixes' take on how much JScript I have to write(CSS is easy, JScript, not so much), and additional 'features', etc. are based on how many DB tables and SQL code I have to write. I don't have a magic equation or anything, I just figure out how much work it will take and how hard it will be to do it. Use your best judgement, but always err on the side of caution.
:)
YEAH, I posted my first 'good' comment in a while. hehe, karma went from terrible to bad
Anyways, enjoy!
NO~, I read Slashdot because I think it's stupid.....
Why are you writing for a platform with no documentation? Either the platform was developed in-house, in which case the respective team should be shot, or you're licensing it from some company that should have written documentation already (otherwise you're paying too much for it, even if it's free).
I adblock all animated gifs.
Blessed be the prime numbered slashdotters
To take a leaf from Star Trek just do what he always did. Say it will take 3 times as long as you think it will, and you will always get half that time to complete it. And if you get it done early you will be rewarded.
Win-win.
Count how many dumbshit managers with no technical knowledge you have over you.
Double your realistic estimate for each DM.
Skivvy Niner? Email me!
HEY! Look left just ONE MORE TIME!
Seasoned developers look back at their experience for similar things, pull a number out of their ass, and then double that number. Just like stock market analysts and economists can't predict the future, neither can you.
I've been developing as a job for almost twenty years, and I still don't know the answer to this question.
The best approach I've found is to decompose the problem into chunks that are small enough to give a reasonable estimate of, but I've hit two snags with this:
1. it may take time I don't have to do the decomposition
2. managers don't like big numbers
Good luck!
Dunx
Converting caffeine into code since 1982
Just Google "software estimation" and you get a variety of ways of doing it (the most popular formal model is COCOMO). In the real world, most people don't have the luxury of doing estimates the right way. In my experience, the stakeholders want a good guess at first (aka SWAG, OOM, VROOM, LOE). They treat that initial guess at the high watermark and then expect you to either finish early if all went well or finish on time if there were problems.
How I go about making this initial guess is by breaking the project up into sub-projects and then creating a baseline estimate by determining how long it would take me to do each piece myself. I then determine which person on my team will be working on which piece and then adjust from the baseline for that component based on the engineer's performance level compared to mine.
Once I have all those man-hours calculated, I double it. This is now my code and unit test estimate. Finally, add 10% for project management and another 25-50% more for quality assurance.
It seems kind of loose, but it works for me.
For the most part, your ability to give an estimate on a change is a matter of experience. General experience will give you a rough idea of how long it would take to implement some random feature. Specific experience with the system in question will give you a much more refined ability to make an estimate. If you can't make an estimate, or you can only make a rough estimate, be upfront about it. Tell your manager or the customer (if you're the one working directly with the customer) that your estimate is very rough, and try to add as much buffer time as possible. Also, don't get into granular estimates when you can only give a rough SWAG (Some Wild-Ass Guess). If you think it'll take you an hour, say a day. If you think it'll take you a day, say three. If you think it'll take you three days, say a week (experience will tell you how much buffer to add). If you don't have enough experience with the system to make a good estimate, ask your co-workers for help. It's always better to under-promise and over-deliver than the other way around. Besides, while you may end up over-estimating some feature, chances are you also underestimated another one and the extra buffer time you don't need for feature A will be invaluable to finishing feature B.
To help you make better estimates, you should make sure you get a solid set of requirements from your customers. Time should be spent with the customer to determine exactly what it is they want (they may not be able to articulate it clearly), and whether or not there's already a solution they could use if they're only willing to change their process. Avoid telling the customer at that point whether something is "easy" or "hard" (and definitely ignore them when they suggest something will be easy -- they don't know the inner workings of the code, so how will they know if it's hard or easy? Changing a piece of text may look trivial, but may involve a number of external factors such as localization or legal that would turn a 5 minute fix into a two month battle). Take what you've learned, distill it down into a solid set of requirements, and take that back to the customer for sign-off. Once they've signed off, they don't get to change their mind any more for this cycle (however long that may be -- days, weeks, months, or even years, though hopefully not nearly as long as that). Then you get rough estimates from the developers based on their gut feelings and knowledge of the code base, and have them investigate deeper to solidify those estimates. At that point, you have enough to build a schedule, but allow for buffer time! A developer's 8 hour day may not be 8 full hours of coding. It may be 4 hours of coding, two hours of meetings, an hour for lunch, and an hour of "filler" for the cost of task-switching depending on how the coding hours and meeting hours overlap. Based on your experience with past projects, you should have a good idea of how much time per day a dev actually gets to spend on coding and use that to build your schedule. For example, developer estimates are all in 8 hour day increments, but you know from experience that developers average 6 hours per day of productive work. That means a 5 estimated days will actually take 6.7 real days, so use that as your buffering criteria. (BTW, six hours of productive work is actually high. In most cases, it's really closer to 4 or 5.)
Finally, don't forget QA. Just because a developer has confidence that he can implement a specific feature in one hour doesn't mean it won't take QA a week to verify all of the ramifications of that change. You really need to have your QA team working in lock-step with your dev team. Your dev team should write technical specs on the features, and your QA team should estimate impact off of those. The "agile" disciplines that are en vogue lately try to incorporate testing directly into the development process, which is good. However, that means that developers will be in charge of including QA costs on their estimates, which developers are usually bad about doing
Wideband Delphi These words added to get past the time filter on slashdot
He said "double it then raise it to the next unit of time."
One hour becomes two days. A week is two months. A month is two years.
P.H.: If you are reading this I'm still in the business.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
As others have said, you should estimate based on similar tasks, and then overestimate before giving that number to management. But there's also something to be said for being honest. Most management types I've dealt with are just fine when you say "I don't know if the application allows us to make that change quickly, so let me do some research and get back to you tomorrow with an educated guess." It helps if every so often you come back to them before the end of the day and say that it was an easy change and you've already finished it. Finally, when working on more than a few things at once, I make sure there's a prioritized list that I'm working from that management is aware of (so they understand why the latest request will take more time) Also, I make sure there's regular progress on one or more high priority items. Management and customers always sleep better when they see forward momentum even if the deadlines slip a little. Spending a week with nothing to show makes them nervous even when things are on time.
Giving an estimate is really giving an expectation. I try to answer the estimate and share my confidence level of that estimate. Plus I try list any caveats that might impact the estimate. If I tell a boss something will take about a week, but I don't have much confidence in that estimate because I don't understand what the user is looking for, that much better than guessing two weeks and finishing in one. I find bosses to be far more understanding of missed deadlines if they have a reasonable expection of missing a deadline.
This is a boring sig
Come up with your estimate as usual (I'm talking your REAL time estimate, coordinating with your team members, not using the schedule handed down from on high PHBs)
Multiply by 250%
Add at LEAST two weeks on top of that.
Tell your (un)friendly PHB "the schedule is NOT negotiable (for acceptable quality) unless they start cutting back features, oh and as a friendly reminder, PHB, throwing more programmers into the mix this late in the game will NOT speed things up, and outsourcing it whole or in part to India can guarantee that the schedule we just handed you will double or triple. Now, does this schedule look good for our shareholders or do we start scaling back features?"
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
This is my method : I list out all the steps necessary for the task to be completed. I then make an initial estimate on how long each task should take. I then go back over the list and add a confidence interval which is a percentage certainty that I am on how long each task should take. I then create a min/max time for each task based upon the confidence interval.
:-)
Draw a line through the min column. Min column is just for amusement. Total the max column and then double it.
If you feel like you need more fudge factor create a confidence interval for your confidence interval and then double that resulting max. Repeat until comfortable.
There's a gorilla from Manilla whose a fella that stinks of vanilla and has salmonella.
If you can't give a reliable estimate, say "I'll get back to you with a time estimate." If they press you, give an estimate on how long it will take you to give an estimate. E.g., "It will take me two days to research the request and give you a reasonable estimate."
The worst thing you can do is to just guess. If you guess too low, you look incompetent when you don't finish on time. If you guess too high, you create the expectation that all your estimates in the future will also be too high.
So my advice is, politely avoid giving estimates until you can research the request. Most people will understand that it takes a little research to come up with a good estimate.
Why not take the Mr. Scott approach to software engineering? When your asks you how long something will take figure out the time you're going to quote him, multiply that by four and then tell him that. If you get it done in the time you'd thought originally you'll look like a mircle worker, if not you've got lots of extra time to finish the project.
What if the entire Universe were a chrooted environment with everything symlinked from the host?
You know, Wild Ass Guess.
Look out honey cause I'm usin' technology
Ain't got time to make no apologies
If a client insists on an accurate estimate of "how long it will take" for a non-trivial project, then you pretty much have to get them to provide you with or pay you to generate a requirements spec, a functional spec, and then an implementation spec. From the implementation spec, you can then ballpark how long each part will take to code and test. If the client balks at putting exactly what they want on paper, then you should balk at providing any kind of estimate; because there is only one truth in that situation: it will take as long as it takes.
This might help:
Painless Software Schedules.
"I think it would be a good idea!"
Gandhi, about Internet Security
This might help: Painless Software Schedules.
"I think it would be a good idea!"
Gandhi, about Internet Security
Use the analogue computing method.
1. Assume you know the development time T of the project
2. Realise the actual time is actually 1.87*T
3. Press the start button
4. Wait for the system to reach steady state
5. You now have the value of T
6. If the system never reaches steady state, you know realise that wasting time estimating how long this will take, is what makes them take longer.
EMail: 0110001101100010010000000110001101110010 0110000101111010011011100110000101110010 0010111001100011011011110110
Okay, so here's how I do it:
First start with one day: this is for a single page of static HTML with graphics.
For every buzzword the client uses, multiply by ten:
Can we have some Flash? (ten days)
And AJAX, too? (100 days)
etc.
Am I serious? You decide.
Estimate the time you think it will take and multiply by 1.5 to 2.0. You need a fudge factor for unforeseen problems, scope changes and so on.
It is better to overestimate than underestimate. For example, let's say you get a big fat contract with an open checkbook. Now if you go over the estimated time you or your employer may have to eat the difference. The person signing the check may call bullshit on the over budget project, and refuse to pay the difference.
Finish the scope of the work early and your boss may notice how hardworking you are. Hell you might even get a big fat raise for getting the job done under budget.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
At the other extreme, if you're developing a "platform" you're in the realm of philosophy or mathematics where it matters more how well you conceptualize the system and you should probably just forget about estimates and go for quality. Yes, that means you can't go to VC's for financing deep system software.
Seastead this.
Don't expect anything on this list to solve your problems.
o Break the problem down into small pieces. If you have an item on your schedule that says "Do X" and the estimate is "two weeks", you do not understand what X is. Keep splitting it into X.1, then X.1a, then X.1a.ii, until the pieces are all less than three days, preferably much less.
o Clock time != development time. You will spend half your time going to meetings, preparing TPS reports, and making phone calls to find out why your test server is down. To convert development hours to schedule hours, use a factor of two.
o Keep an estimator's handbook. Ever noticed these in a technical bookstore? You can look up how long it takes to plumb a bathroom, build a wood frame wall, etc. Keep your own list of how long it takes to build a credit card form or a bulletin board. Look up the phrase "function point" in ancient literature and see if you get any useful ideas.
- Get the requirement in as much detail as possible. Having items sliced such that they are actions/changes that I think I could do alone in a 2-3 hours or less.
- Then I gather PMs (count the number of activities) and multiply by 2.5
- Then talk with some co-workers, ask them how much they calculate. Most of my coworkers get their numbers by feeling, so only if their guts ask for more time I re-check my number.
- Profit!
As you do it over and over you'll become more adept at detailing your activities. Experience helps you add more activities that are more realistic. (Of course you should be improving your skills so things once took more time should lower) In the end I could rephrase, get your optimistic time and multiply by 2.5Most of the time I get a number which sounds huge, but I tell myself you ain't be doing just that, and emergencies happen. So even if I think it could be inflated I stay with the number. My changes are "critical" so most of the time others understand that I won't rush.
I'm still new to estimates but this method had worked for me in at least 3 big projects. If you have to work with others, you need to find their factor, in this case 2.5 is my "weight". When I said activities I'm refering to such things as doing each and every use case, coding each function, doing UT, peer reviewing, and so on. All that's required, even talking with the guy next cube so he can't configure some bizarre environment that I will test. Everything counts. Hope it helps.
I have several methods of estimation which are used in accordance to the type of job, and timeframe required in order to get the estimation. Sometimes I have small jobs which can be almost estimated on the spot providing I'm confident with the level of technical risk involved. Sometimes I have long term jobs which require a decent breakdown of tasks. That's a fairly broad description of what happens, and of course these estimates can be affected by deadlines (which are always negotiable, never let anyone tell you otherwise)
What I look for when performing development work, is what constitutes an item of work, a small package which has *roughly* the same development period everytime. For example, you may find that when developing a web based application it takes an hour to code a page, including testing, that's your quick estimate tool, calculate how many pages and there's your *rough* hours. On top of that, add your contingency. Or use the manufacturing rule of "double it and add it again" (after all, you are, as a developer, a manufacturer. I just wish I could claim the same tax breaks). Of course, some pages may take less, some may take more and it is a rough science, I don't suggest you sit in front of your computer with a stopwatch and time a page write, but if you've done enough of any task you should know how long it takes you to perform it.
The other problem associated with estimates is your own confidence in what you've calculated. You mock up something on paper, work out the units, do the math and come up with what seems to be an arbitrary number. Is that enough? - Well, you can go over your figures multiple times, throw in what-ifs, work everything out backwards if you like. I can almost guarantee you that your first figure is the correct one (unless you've forgotten something major from the first calculation) So I tend to stick with that nearly all the time.
Then there's the choice between Time and Materials and Fixed Cost estimates. If your job requires the actual quoting based on either of these, choose T&M (if you *can* get away with it, if your client feel flexible that day then T&M can help with your contengency planning a great deal). If your technical risk is 0%, then go ahead and fix that cost. If your political risk is high, say you've done the same kind of work for three companies who are in competition with each other, T&M is a tool for at least getting *some* kind of payment in case the situation completely explodes, like they find out you do the same work for their arch rival, you haven't signed an NDA, debtors fall into 120 days, or they turn up with baseball bats and offers of one way fishing trips (here's some advice, try to avoid working with fisheries, sometimes you see more than you want to)
OK, to tie the above off, estimation was never meant to be fun and uh, don't undercut me. Thanks.
Task Mangler
I use my previous projects as benchmarks. If, say a certain old function/project's difficulty was x, and it took me n days, and the new function/project needed was twice as hard, I'd quote 2n days. That's an oversimplification but it worked for me. Steve McConnell's books helped me a lot. Like this one: http://www.edv-buchversand.de/mspress/product.asp? cnt=product&id=mp-0535
And I always gave 100% padding. If I know it will take me a week to do it, I usually say I can do it in two. (Duke 4ever comes to mind but that's another story.)
I use my old projects as benchmarks. If say an old function/project had a difficulty rating of x, and it took me n days to finish it, and the new function/project needed was twice as hard, I'd quote 2n days. (Plus an additional 100% for padding.) I have found Steve McConnell's books to be helpful, like this one Software Estimation: Demystifying the Black Art http://www.edv-buchversand.de/mspress/product.asp? cnt=product&id=mp-0535
That's an oversimplification, since there are many factors, but it works. There's really no cut and dried way of estimating, but you can come close.
Time estimation is part of project managment. A good course in project management will give you the tools to effectively deal with these situations.
Short and sweet, when asked to give an estimate (any estimate) ask them if they want the quick and dirty estimate now (which may be off by 1,000% or more) or if they would like a more accurate estimate. If they want the quick and dirty then use whatever method you use now to give them the estimate. If they want an accurate estimate then tell them you'll research the current state of the project, the development effort required for functions x, y, and z, and the resources required to accomplish the effort.
Then follow a good estimating process - there are many available in many books about this subject. In my case generally new projects are very similar to older projects, and are all built on the same foundations so it's easy to start with a list of tasks to get from point A to B, and list the resources and dependencies for each task. Link them all together, and then go to the boss and say, "Assuming that we have these people and these reources, the project will be completed x weeks from kick-off."
When (not if) the boss says, "Well it needs to be done by this date!" Calmy reply with, "We can meet that goal by either scaling the work back, or increasing manpower. Which is more suitable for this situation?" and so on.
The one thing you don't want to do (that all too many software engineers do on a regular basis) is over estimate or underestimate the work required. In either case the customer (generally your boss) learns not to trust your estimates. This is bad on so many levels, and is the main reason that so many software engineers work more than 40 hours per week on a regular basis - especially those that overestimate the time required trying to combat this (paradoxically).
A more accurate estimation process will include a frank discussion of risk and risk management. "This schedule is good as long as we assume the code base is well documented and follows reasonable coding practises." Then find out what the customer wants you to do if you find this assumption to be false. Give them the whole scenario - the risk may be low, but if the assumption proves wrong then perhaps the project schedule or resources just tripled. That may be too great a risk to take even if it's unlikely - so how do we mitigate that risk?
I could go on, but really this is a basic question that millions of people have asked for thousands of years. There are much better and more thorough resources to answer it. Visit your local library if your company isn't willing to send you to a simple three day project management seminar. They won't teach you much that's new, but they'll tie it all together and give you the tools you need to communicate effectively with others - most of the important stuff is being able to say, "I'll get back to you on that by thursday."
-Adam
Don't do it!
I'm serious. If we've learned anything over the past forty years, it's that trying to estimate software development time is a waste of time. Why? Well, for one things, bugs. To know how long it would take to find and fix them, you'd have to know what the problem was, which means the hard part's done. For another thing, specification flux. Most reasonable project specifications for non-trivial projects don't provide enough information to accurately predict how long it will take to code. And producing such specs, and using them, will take longer than the development would have taken in the first place. And, if that's not enough, think of Dilbert. Specifically, the one where his boss asks him "Will there be any unforeseen problems?"
I once told a client (a dot com) "I'll tell you how long this will take if you can tell me what you stock will be worth six months from now, four months after you IPO. And I'll be more accurate than you will. If you'd rather, you can tell me when the next two-day rainstorm will be." He hemmed and hawed, and basically refused to give any sort of number whatsoever. I said "Good, it looks like we've got a nice honest relationship going here. Neither of us is willing to lie to the other, or claim to know something we don't. So let's start prioritizing these features for the mock up."
Let me say it again: Don't even attempt to estimate development times.
So what should you do instead? Incremental development with frequent opportunities for feedback. Ideally, the users should be able to play with a nightly-build prototype whenever they want from the first week or so on. If they ask for a time estimate, tell them it will be done when they're happy with the result, and don't want anything more, or they're unhappy with the rate of progress, and call the whole thing off.
But don't lie to them, no matter how hard they push.
--MarkusQ
A fellow developer taught me an approach that's been especially useful to me. Certainly you get as much detail as possible about what you are expected to do. Certainly you break that down into as detailed a set of tasks as possible. But don't estimate in hours or days, estimate in lines of code (yeah, yeah, lines of code don't mean squat, tough it's all you've got). Do all the estimates in lines of code. When that's done convert to time (say 500 lines per month, maybe you even know you net lines of code per unit time - remember from start to finish - designed, coded, tested, and deployed).
... "they're 10 of them, and they look like about 200 lines each ... 2000 lines".
The biggest advantage of this technique is that you change the way you think about the problem. Instead of thinking "how long should this take", you are force to think "what do I have to do". You can look at blocks features and say
The change in point of view is crucial. Need to know your (or your teams) "lines of code": go back to a previous (preferably similar) project and measure it. How many lines of code were there at the end, how long did it take (elapsed time, don't take out the garbage it'll be there next time), and there you have it.
While you might get some grief for refusing to estimate time, it will be far less than you'll get for being wrong. And since, in the long run, that's your only alternative, you are far better off simply refusing to estimate at all.
Besides, it's pretty easy to push it back on them. Since you clearly can not know how long it will take, or even estimate it with any confidence (again, for a non trivial project) they are in effect asking you to lie to them. So if they insist on an estimate, just insist that they agree (in writing) that you'd be lying to tell them something that you can not, even in principle, know, and that that is Ok with them.
--MarkusQ
In order to give a proper estimate, you need to be able to sit down with a piece of paper and break a 'job' down into it's atomic parts. While I'm being very vague about the word atomic, I'm doing it for a reason. It means different things in different contexts. In a year-long project, it may be an entire module, feature, or class. However, if you're breaking down your day's work, an atomic piece might be a particular method. Only when you've created a blueprint of your work and a priority list, can you effectively determine how long something will take. Oh, and multiply that number by 2 or 3.
Frankly, that's what your managers should be doing. Of course, they figure they can just slop an assignment in front of someone and ask how long it can take. Scotty says it will take a year, and he just can't 'give any more, cap'n'. When managers ask dumb questions, they get dumb answers.
See, there's really a much deeper political problem here. It looks like you customizing your existing app out the @$$ for your client and your boss is riding your behind to maintain undocumented code. This will deteriorate the code base! I'm guessing refactoring isn't a priority here. There's nothing wrong with doing this, provided you realize your code base will need to be thrown away if this trend continues. This practice has the additional effect of burning out your developers as well. Frankly, when you have little documentation low turnover is crucial. It also looks like there's a lot of bad software engineering going on here too. You're being asked to give estimates because managers can't give estimates. How can you even begin to follow the process I described above if you've got no requirement or design to begin with. My advice to you is guesstimate and CYOB. Also, it sounds like you're having to reword (or atleast clearify) a client's requirements. Once again, this sounds like a project manager's job. Sure, they can come to you for advice, but there's a point to where a manager needs to be taking some inititiative. Lastly, there needs to be some real management going on here. They need to cluster tasks. Often times multiple features are implemented in the same code, having multiple developers over a short period of time working on the same code with overlaping code enhancements is just not good appropriation of time. Of course, this all ties back into the lack of technical/project management from day one.
Oh, for your own sake, if this is what the whole company is like, look for a better job. Keep your feelers out, because you can't run a SaaS/ASP/software shop like this and make money.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
You can always do what management does: you pull numbers out of your ass.
The only problem is that, unlike them, you may get held to those numbers...
The last thing you ever want to do when asked by a manager is give a off the cuff answer. It will almost always be wrong.
So what do I do when I get asked how long something will take? Well, to start off, if I know the code in and out, and I'm aware of the bug, then I can actually estimate what amount of time it will take. If it's not a bug, but something to be developed, and I've done the exact same thing before in my career, I already know the answer.
If however, neither of these are the case (which is about 98% of the time), I say this: "It'll take me roughly x hours to investigate this matter further and only after that will I be able to give you a timeline that is accurate."
First off, that gives you way more credibility, and way more leeway. But second, it lets you dive into the situation without having committed your life to fixing it, until you get a better grip on what's going on. If I were for example dealing with a bug on a web app (the kind I regularly work on these days), I would say something like "It'll take me 4 hours to investigate". I will most likely start with about an hour spent understanding the scope and possibly the history of the bug. "Is it reproducible?" is the most important question. If it is intermittent, I will commit to nothing at this point. If I look at the code and can see what is causing the problem, that is, if I can see a clear cause and effect chain that agrees with the test cases etc, I rely on my prior experience and make a guess at how much code needs changing. Plan for it, and plan conservatively. *DON'T* rewrite the application. Only fix the problem.
If you have time left on your initial x hours, start fixing the problem. See how it goes. Does it look like it's just going to keep on going like this until you fix it, or are you finding your being faced with odd and quirky behaviour left right and center? If you have weird behaviour, beware! If you have undocumented libraries/APIs behaving weirdly, beware! Don't get caught with your pants down. Let your manager know that you are passing some data down to the J2EE/COM/.NET/.Salsa/<NameYourCustomFramework> and that it is not acting as expected.
For actual development, the process is slightly different. Assess what needs to be done exactly in the same way as above (give an initial x hours to investigate). See what actually needs to be done. *DON'T* rewrite the STL library or .NET framework to do it. Choose the quickest cleanest path with the least amount of development time. Look at all your prior experience: have you previously used STL? Do you know it like the back of your palm? Have you only briefly used COM? And have you had issues with it the times you did use it? Keep that in mind. Try to steer the project in your domain of expertise. Put that as a coefficient in your estimation. If you know you have 100 lines or so of code to write using a library that you know in and out, estimate what you think it will take. If you will have to use a library that you're not really familiar with, pad it like crazy. I mean 2-3-4 times what you expect.
Those are the practical comments, there's also the more theoretical stuff:
Don't confuse accuracy and precision. And don't let your managers confuse the two. If I am asked to guestimate a project timeline, saying "4 months, 3 weeks, 2 days, 5 hours, 23 minutes" is more precise but radically less accurate than "4 months". Yeah, it sounds stupid, but accuracy != precision. Don't forget that. Tattoo it on your hand if you must. The longer a duration, the less precise it should be. Commiting to February 5th is ok if you are in January, it is not ok if you are in August. If you are in august, you must commit to a month coming up, and warn your managers to give it leeway. Just cause you said "it'll be done in february", doesn't mean they should plan a launch on February 18th.
The other thing is a little concept that I really like in comp sci algorithmics: divide and conqu
"To thine own self be true." -- Decide how "tough" the task is in instinctive units. Never reveal these to anyone. This is what you track for yourself. At the end of every project, evaluate how close you were on your "toughness" estimate, and adjust your head accordingly. This has nothing to do with how long it took you to estimate; it has to do with whether the job turned out surprisingly easier or harder. You'll be surprised how quickly you can get good at this estimate.
Keep a time_multiplier. If you have the luxury of working for a single employer in a stable environment, this will quickly converge. Each workplace will need its own calibration however. Also keep this one to yourself. After every project, see what your "hardness * time_multiplier" predicted (hardness after the adjustment above). If you are low, bump your multiplier; if you are high, drop it. This also can converge quite fast.
Now the political parts; much mushier. Never state an estimate before you have a confident feel for the "hardness" number; give "estimate estimates", of the form, "I don't know, but if I drop everything now I can give you an estimate in 6 hours (or 4 days or whatever you need)." Estimate estimates are also easy to get good at, but hard to sell politically. You have to stick to your guns here, or you are sunk.
Once you have your "hardness", and your "time_multiplier", you have what you really think it will takye you to do the job. Now you need to throw in a political_factor. Some bosses will take your estimate and give you 75% of the time (figuring you are padding). Learn to pre-multiply for those.
Some bosses will understand you are projecting the center of a distribution; be very straight with those (and stay with them even against an offer of 120% of your former pay).
Some will "negotiate" with you; I once was successful in one of those negotiations when I said, "I thought you wanted my best estimate. If you don't, just make up any number you like; it won't affect how quickly the job gets done." Be very careful to distinguish these people from those who are willing to change the task to fit a schedule. For those people, you may have to hit them with another "estimate estimate," but switching details usually quickly gets to wher you can do some on your feet.
Summing up. Track "hardness" and avoid connecting it to any "real" idea of time. Keep your instinct of "this should take a day" and learn separately how long it takes you to do what you think of as a day's worth of work. Track "workplace factors" collectively separately; this covers things like how many meetings happen, how often you rebuild your machine, .... Finally, track what you need to do to your true estimate to "sell" it.
Selling may be inflating in expectation of an automatic deflate. It may have to do with how your bonuses are calculated. It must include lots of factors about what you tell your boss. Finally, it can also include a cost/benefit analysis ("If I say 78 hours and I come in at 83, we lose our shirts, but if I say 78 and I come in at 72, we don't get the contract"). Sometimes low is too expensive so you pad, sometimes high is too expensive so you shrink.
Go read The Personal Software Process. It's full of helpful, common sense suggestions that every programmer should know. Then go read The Team Software Process, which is a simple forward thinking way of getting programmers to work well together in teams. Then get really really depressed because no matter how hard you try at stuff like this, the software industry is so random and unpredictable that common sense is not all that common.
How we know is more important than what we know.
It is nearly impossible to predict the actual delivery time for a programming project because there are too many dependent variables. (For a good pciture of the problems caused by independent variables, read Gordratt's books, "The Goal", "It's Not Luck" and "Critical Chain". "Critical Chain" leads you to the best insights for your position, but the other books are essential prep.)
http://www.goldratt.com/
There are two keys to delivering almost always on time; Planning and Management.
Planning means thinking the project through in the best detail before you start coding. Agile programming seems to work in short, quick-and-dirty projects, but my experience is that it falls short if the project is large and complex. The less decisons you have to make in the middle of the project, and the less changes you have to make as a result, means that the work can me seen to progress along the planned path.
Management means controlling the variables, and that's where the techniques in "Critical Chain" shine. Nothing, absolutely nothing, is allowed to delay the critical chain in the plan. The biggest dividends come from two parctices: Continuity and Resource management.
It used to be that if I had a week to do a job that I knew I could do in a day or two, I'd do whatever else needed doing and start two days before the task was due. Of course, If something came up, (essential co-worker gets sick, computer crash, virus, software needs updates, whatever) then I might be delayed during that two days and the task is delivered late. If the task was on the critical path, then the whole project becomes late. The first 10% delay on a project typically costs 25% of the profitability, the next 10% late costs 20%, so being only 20% late can cost 45% of the profitability. People tend to think that if they have some slack, they can relax. Then they wonder why they are late. They should work as if there was no slack! Relax at the END, not during.
In a large project with multiple developers, some of them may be required to cordinate along different paths, not just the critical path. This is why Godratta called it the "Critical CHain". Those resources MUST be focussed on keeping the essential workflow from bogging down anywhere that may delay the longest chain of dependencies.
This idea came out years ago, and I've been following project management ever since the 60's. This is the first big change I've seen since 1969. Everyone who told me they tried the Critical Chain method and it didn't work, didn't follow the process. Siemens practically took the whole market for 7200 rpm hard drives by developing them first using the Critical Chain method.
Good luck on your projects.
"The mind works quicker than you think!"
http://en.wikipedia.org/wiki/Hofstadter's_law
I spent two horrible years in Ohio. I moved there just after one Christmas, I seem to remember a Chistmas in between, and then I moved just after another Christmas.
* Break all down the requirements into the smallest steps you can
* Take a look at the steps and write down your gut feel on how long it will take on a system that you wrote and know well^
* Double it
* Double it again if you are not familiar with the system
* Add 50% if it is in a language you are not familiar with
* Add 50% if the code is Convoluted, Uncommented or generally WTF
* Add 5 hours for compiling/deployment/support
This is certainly worst case estimates, so tell your customer that, but better to come in cheaper than overrun.
^ You will always underestimate this step, just human nature
ask the interested party how long they think it will take. - add 20% rinse and repeat
Right now, I would tell you I still need to either write or learn preexisting libraries suitable for undertaking such a task.
When I go about writing in general, I see what others have written on a topic, and then I see what elements I like and then go about to putting it all in my own organization and turn of phrase.
When I can't reach a 80% to 90% confidence level that I can give an accurate estimate I do something different.
I don't give an estimate how long it will take to develop said feature. Instead, I give an estimate as to how long it will take for me the give the accurate estimate.
So, for example, I will say, I need 3 days to write some test-code, do some reverse engineering, and try to get part of the feature in, and in that time I am 90% confident that I will be able to give an accurate estimate then how long it will take to fully develop the said feature.
It has always worked very well for me to upper-management, as long as you then come in with a good educated answer how long it will take you after your first estimate.
It's better than giving a blind non-educated answer the first time around.
Modesty is one of life's greatest attributes
The reason why trying to estimate times is a useless exercise is that you can only get a reasonable exercise if you can break the problem down into tasks that resemble similar tasks that have been done before.
But... ever since the days in the 1950s when the subroutine was first invented, there never should be such a thing as a "similar task." Anything that was done before should have been packaged as a subroutine. Or a reusable object. Or a programming system (entire library or language) designed to attack that class of task.
Managers that prize predictability over productivity assign their people to do trivial variations of the same work over and over again and get a predictable straight-line curve of time versus work accomplished.
Good managers allow their people to invest time into tools and techniques are new, hence risky, but pay off with a multiplier effect when they work. They get an unpredictable but exponential progress curve.
(Bad managers, of course, won't accept the notion that a new task should be estimated at the time that a similar task did in the past. They insist that the task should be estimated as if everything were going to go perfectly this time, no missteps, no problems. ("It will take about a year." "Why do you say that?" "Because, remember, the last time we developed the frammis for the foithboinder project, it took a year" "Yes, but a lot of things went wrong. We had several false starts, because the original spec we were given was wrong. And Jim left halfway through the project and it took a while for Kathy up to speed. And we lost a month when we changed over to the new source code control system." "And why do you think nothing will go wrong this time?")
"How to Do Nothing," kids activities, back in print!
first one, of course, is: "How can i make a woman tick?"
i just don't devote any more time to these 2 questions anymore...
I don't feel like it...
My technique is to take my first guess on the actual coding effort involved, double the number and up the unit. So, for example, 5 minutes will probably take 2 hours; 1 hour will probably take 2 days, and 1 day will probably take 2 weeks. When all meetings, documentation, testing and other non-coding activities are taken into account, this method is usually very accurate.
I can't tell you the method directly, but I can give you a hint: It involves a full set of Yahtzee dice, a Scrabble board with tiles, and a really cute blonde with dimples.
Would you like an estimate of the cost of the estimator?
I have a rule of thumb for database applications that seems to work: Count the number of tables involved and multiply with 3 is it is within a known problem domain, and multiply with 5 if it is not. The the reason behind this, is that each table require a definition (1 day), an input form (1 day), a report form (1 day), testing (1 day), documentation (1 day). Definition and documentation can more or less be left out if you're in a known problem domain.
Then, if you wan't to give the estimate in calender time, you should add another 25%. One day a week is typically being spend on other things like meetings etc.
When asked how long a project will take, I've told Project Managers "I'll tell you after I'm done, because that'll be the first moment when I can give you a precise response." They don't like to hear that, of course, because it doesn't help them do their job (scheduling and tracking the project.)
It's true though; as long as there is still work to be done, there is uncertainty in how much effort is needed to complete the work. There may be a lot of uncertainty or just a little, but there is always some, until the work is completed.
As Software Engineers, we need to accept and embrace the fact that this uncertainty exists, account for it, and help our Project Managers to account for it too. Afterall, they need to estimate risks to the project, and getting a quantifiable handle on uncertainty will help them to do that.
My approach to estimating:
Typically, I'll provide my initial estimate as a single task, with a wide range between the min and max. If the Project Manager needs a more detailed estimate, I'll ask for some analysis time, and I'll spend that time breaking the large task into smaller tasks, providing estimates for each. Since these tasks are smaller, they'll typically have narrower ranges than my original estimate, even when I add up all of the mins and all of the maxes to get the overall estimate. This task breakdown is iterative, reducing tasks down to the point where the Project Manager is happy with the units (typically effort-weeks or less) or when the analysis shifts from being primarily estimating to primarily design. Also, as I'm breaking the tasks down, I'm also providing information about task dependencies. This allows the Project Manager to put this information into a Gannt chart / Work Breakdown Structure, which helps the PM to track the project and communicate estimates to upper management.
To reiterate, you determine the overall estimate, you add up the minimum estimate for each task, add up the maximum estimate for each task, and use those as the overall estimate for the overall task. It's ok to use larger numbers with small units when you do this, because you're working with more precise estimates than when you estimated the initial overall task.
To turn this estimate into a schedule, the Project Manager has to account for a variety of factors: the starting date, the weekend/holiday/vacation schedule, and the percentage of your time that will be spent actively working on the project. For me, the last factor is 60% / #concurrent projects, assuming equal priorities. That is to say that I spend 40% of my workday on non-project activities: answering email, attending meetings, doing HR-related stuff, and doing maintainence work for software I'm still responsible for. The 60% of my time is divided amongst the projects I'm currently working on, proportionally to their priorities.
One nice aspect of this approach is that, as tasks are completed, their estimate
Generally, I've found that my boss will first tell me when he wants it done or needs it done, and then ask me how long it will take. So it boils down to a yes/no question, to which "yes" is the correct answer, for him.
How lomg will it take to do this ? The answer is always this question: How long does it take to catch a fish ?
I've read two really good items on the subject of estimating software schedules. The first is Painless Software Schedules by Joel Spolsky, the Joel in Joel on Software. It's a quick read, and a lot of the comments here are giving the same advice all spread out. Even more useful is Waltzing With Bears by Tom DeMarco (ISBN 0932633609) (very talented author, I strongly recommend Peopleware to everyone), which is about managing risk on software projects, especially as it relates to time. This is one of the fundamental errors in the question "How long will it take?"--the inquirer wants an exact amount of time, so if you say it will take four hours, it should take exactly four hours. The problem is, you may luck out--someone may have had that feature in the program once already, and it was removed, so all you need to do is call some fully-tested code from a different place, or there may be high coupling, so that what looks like a really simple, straightforward change is insanely hard. Those two factors put together means giving an estimate should be something like "No more than forty hours, 75% probability of finishing within twenty-four hours, 50% chance of finishing within six hours, 25% of finishing within four hours, no quicker than an hour." As part of Waltzing With Bears, Tom DeMarco (and I assume others) put together a Riskology spreadsheet, intended to allow you to estimate schedule probability curves, which allows combining multiple probability curves to get an estimate more like "No faster than eight months, 75% within six and a half months, 50% within five months, 25% within ten weeks, no faster than four weeks." And always make sure the first number people hear is the worst case scenario--that's the one they're going to remember.
Other reading:
Coding Horror, How Long Would It Take If EVERYTHING Went Wrong?
Software Estimation: Demystifying the Black Art by Steve McConnell
Google on Estimating Software Projects
Sigs are like bumper stickers.
Note: This excludes from the definition of "software development" vast areas of useful and productive work, that may in fact be estimable. Configuration of an existing method, via a user agent, is not software development. Example: IMHO, developing a spreadsheet does not require the eureka factor.
(Process Red Herring) Superficial simlarities between projects, such as personnel or architecture, are irrelevant as they are orthogonal to premises (1) and (2).
(Process Red Herring) True repeatability, doesn't happen, by definition as (2) requires the method be "new". Performance on past projects provides no indication of future performance.
(Process Red Herring) As we are not dealing with physical effort, adding more physical resources (personnel, machines, etc) does not make the effort more predictable, or committment, more reasonable.
Political correctness be damned comment:
Yes, there really are stupid questions, and disengeneous people. Grant me that the world contains many inquisitive idiots. Further grant me that un-ethical management will use threats to deliberately force a developer into stating a date, they want someone to blame for their risky promises.
(Inquisitive Idiot questions that I have personally enjoyed)
I can't tell you anything about the foo project, but I need to know if it will be done by the First of (insert bogus date here) ?"
"This is just like the snafu project, except we'll do it right this time! so it can be done by (insert bogus date here), right?"
"I promised the customer that we would have it on (insert bogus date here), as otherwise they wouldn't sign the deal. But we need it sooner, by (insert bogus date here), when will it be released?"
"This is a simple little change on the screen, to give them the weather forecast next month. Deliver it next tuesday, ok?"
Typical challenge to refusal to give a bogus estimate:
"We can't miss the deadline! what should we do! ?" Candidate Answer: Start earlier next time.
"Ok, tell me how to speed the project up ? What do you need?" Candidate Answer: Enough time to invent and deploy a solution. So minimize interruptions.
My conclusions:
Unfortunately, the noun phrase "software development process" is both mal-formed and dangerous. It causes many people to infer and believe that there is a process in play, that they can influence. There really isn't, its just clever people inventing new things.
The fact that a business needs a schedule, "that development is committed to", is a business problem, not a software invention problem. The effects of that problem include: lost deals, invalid expectations, invali
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
Joel Spolsky had described a simple approach on his website:2 45.html
http://www.joelonsoftware.com/articles/fog0000000
Absolutely worth a read (like most of Joel's writings).
I once worked for an "XP" (extreme programming, not windows) shop. We had not a single line of documentation in our entire codebase. What we did have, however, was 100% test coverage (at the unit tests level, the functional test levele, and even at the customer-test level). We could estimate, as a team, the length of time it would take to implement every feature in a major product change up to six months out, and hit them all on the exact day we had said we would.
It could have been the whole XP process or whatever, but personally I believe it was the testing that allowed us to estimate so well. When something is so well tested, and when you are working from a "test-first" mentality, you get the ability to estimate what you think it will be without having to fudge-factor the results. You do this for a while and you find that your gut instinct gets better and better.
As developers, we always have a tendency to think in terms of best case scenario. And once you voice that best case once, it gets very difficult to get out of a crazy commitment.
So *before* providing any numbers, make sure to list the assumptions that you are making, and the interferences and risks that may (and most likely will) occur:
- other projects and assignments that will steal time and resources
- spec changes and debugging time, customer interaction
Explain that you have an estimate in Effort-Days or Effort-Hours dedicated to the project, but that this is not the same as a Calendar-Day. With week-ends, holidays, admin tasks, etc, count 200-240 effort-days per year.
Explain that uncertainty remains on a number of tasks. You want to give your best-case estimate, but there are things that you don't know, but in practice best case NEVER happens. Provide a more likely estimate taking the risks into account.
Highlight the key risks and challenges being faced. Discuss ways in which those risks could be mitigated: does it make sense to create a first prototype (to check technical feasibility and/or get end-user feedback) ?
Or can hiring a consultant (that you would select) to help you with a specific technology (e.g. set-up that database back-end) help speed things up/reduce risk? (sometimes few hours here and there for a couple of days total is enough). Keep in mind that "throwing more resources" at the task often only worsen's a project's delay (training and communication overhead, etc).
Does not having a quiet and uninterrupted work environment interfere with your productivity? Point this out, make concrete suggestions for improvements.
MBA or not, your manager hopes to just get a number from you, and then bind you to it. Don't let this happen, but don't be confrontational either: you need to establish a teamwork.
It is not about you escaping any pressure from a commitment. But many interferences are out of your control, and Manager might be able to help keep those away.
It is in your mutual interest to have estimates that work. And this is also why you need to keep track of your progress, and notice deviations early on. Be dedicated, and act responsibly. Warn Manager of any delays and problems that occur, so you can rectify the estimated schedule (or the environment) together.
Hope this helps -Ivan
I wrote a tool called Mr Schedule that's based on the Painless Software Schedules technique described Joel Spolsky. I've found the technique works very well.
Cheers
Andrew
This seems to work alright for me:
/..
A = Shortest Possible Time (Ideal Time)
B = Realistic Time
C = Longest Possible Time
(A+2B+C)/4
Then double it so you can spend the extra time reading
Love sees no species.
Creating new code is usually easier to estimate, because once you understand the business rules, you should be able to code it and estimate your time.
Bug fixes, on ANY code ( don't care who wrote it ) can be trickey. It can often be a situation that if you fix one thing your break something else.
There is no real set formula I use, but if I think it will take 3 weeks, I'll say 6. I always double my estimate, and often 'fish' for scope.
Lastly there is nothing wrong with saying 'I'll have to look into that to give you a more accurate estimate. You should be able to take a day or two to get into the code and look at it and figure out enough about it to get an estimate of what is involved. We do this and we call them ballparks. Our ballparks tell how much time the developer needs + qa + spec + IT time + some other things in there. It is usually an estimate.
Then we write a spec, and in the spec we uncover more. Depending on the outcome of the spec and what needs to be added or dropped the bid can change. Also in the spec we identify ALL the programs that need to be changed. These are things that should have been looked at in the ballpark to give you a better idea of what to extimate.
It sounds to me like you are a junior programmer. This has nothing to do with your coding skills and everything to do with your project skills. There are many people who can code circles around me, but they can't always give estimates that are as right on as me. As such, take a look at your code. This should be done in a day no longer. Figure out how much time you think you need to spend on it. Multiply by 3.
After you do this a few times you can start to see how good you are at estimating time. If you estimate time and you are behind on the project, then next time multiply by 4. If you end up ahead of schedule multiply by 2. After a few projects you will be able to say without a doubt exactly how long it will take. Unfortunately some projects will be a range not an exact date, like it will take 6 to 12 months, depending on scope changes.
really though it takes practice to estimate time. Knowing your own skill level, your knowledge of the language and code base, and what other things will always popup, and lastly your interpution level.
I'm sadly the goto guy at my company, so my interruption level is high.
Only 'flamers' flame!
Does slashdot hate my posts?
--
Greetings
... even if it is from an AC.
Two options:
a) Well
b) Poorly
The other post isn't strictly true. Part of the problem is that trying to figure out what's going on with me is confusing. The other thing is that with me things don't seem to obey the time scales other people experience.
What do you look for and what do you ignore to stay on task? A lot of the time the library is a lot to wade through, and then doesn't have relevant examples or somethingh something. Then there is the matter of coming across the library before you can even determine it's appropriateness. It's easier to learn a library or part of a library first, then figure out what the knowledge of the library enables you to do, but that's not possible, with being assigned a project first and then going about to figure out how to do it.
I generally look at projects already in existence and then modify them, to get a feel for things.
How in the heck do you conclude that? Or, to put a finer point on it, what does it actually mean? Other than just artificially defining the terms ("highest priority open issues," "baseline enhancements" and "strategic application development") to support your conclusion, can you actually give a cogent defense of this claim? Or is it just buzzword stew?
Yes, and the answer is (or should be) well known: in general, there is no way to determine the time it will take to complete a software project that takes less time than actually doing the work and seeing how long it took. If you want the theoretical underpinnings, just note that software development is a subset of the halting problem. Given that, we need to go up a level, and ask if there is anything the will meet his needs in a different way. I claim there is, and have outlined the process.
--MarkusQ
Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.
PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.
When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.
And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.
That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co
StoneCypher is Full of BS
I used to believe that design was the most important thing about software development, but as I've grown older (and greyer), I've come to the realization that good requirements are critical.
I've even gotten to the point where I've developed my own requirements tracking system (MRAP - not a very imaginative acronym:).
When a client asks me to implement a new feature, I ask a few pointed questions to narrow down exactly what he wants. I have a template of over 100 topics in a dozen categories to draw upon. If he can't clarify his expectations, then chances are what he wants is unimplementable.
I record all the requirements in a database, organized hierarchically. I can keep all sorts of info such as create dates, authors, update history, authorities, design elements, unit tests, etc. attached to each requirement.
The client signs off on each requirement before development proceeds. (I don't tell him that I've already completed most of the design process by that time.:) On the rare occasions that there is a dispute, I can point directly at the requirement and convince him that it was under-specified, or mis-interpreted. Usually, by that time, he is educated enough that his expectations are in-line with reality.
It's hard to get the client to buy-into the requirements process. He wants development to start immediately, and is chomping at the bit to get something tangible right off the bat. I usually whip up a proof-of-concept prototype to keep him occupied (distracted?) with the proviso that this IS NOT THE FINAL PRODUCT! and will be thrown away in a week. When development starts, the client is often amazed at the rate of progress.
The requirements database is dynamic, always being updated as new information becomes available. It is the source/sink for project feedback. Every little detail gets recorded - emails, test results, bugs. It gets reviewed constantly. Completed items get checked off (and hidden if desired)
Now, to get back to estimation. As the requirements get more detailed, the uncertanties get whittled away, and it becomes easier to estimate - if only based on past experience. Each pass through the requirements allows you and the client to set priorities and define more precise schedules. Those areas that are not fully defined yet can be respecified, bulk-estimated, deferred or deprecated.
A very important part of the requirements is the project completion section. The project is complete when all the items have been marked completed, the deliverables have been delivered and the money is in the bank.
If the client doesn't seem happy at this point, it is time to reopen negotiations - perhaps to start a whole new project, or to abandon the whole idea, take your marbles, and leave the playing field.
regards,
Dar7yl
Especially, there was an article showing that objective estimation of development times is mathematically impossible:
http://cellar.org/archive/index.php/t-638.html
This question comes up in any job. The only advice I can give you is a quote for a tv show:
GEORDI:I told him I'd have that analysis done in an hour.
SCOTTY:And how long will it really take you?
GEORDI: An hour.
SCOTTY:Ye didna tell him how long it was really going to take you?
GEORDI: Of course I did.
SCOTTY: Oh... Laddie. You've got a lotto learn if you want them to think of you as a miracle worker.You've got to --
sorry, had to.
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
Shane
For small changes you can generally guesstimate from exerience with that system. If you know the code well there's a better chance of being accurate. If you have to wade through someone else's code you don't know then be very generous (generally double your guess).
With all but the most trivial changes you need something in writing to confirm what is wanted - even just an email to restate what you talked about and put your estimate in writing. Get in the habit of this. You can talk about it then look at the code for 30minutes and make a far better estimate than being pressuried into giving an answer straight away.
On much larger projects the time spent on actual coding gets less and less and the time spend on specifications, prototypes, testing, documenting, reviewing etc gets much bigger. I recently worked on a $250m sw project where coding was about 20-25% of the time. It depends on what the code is for. Normally coding is about 40% of a project but the more critical a system the less time spent on code and the more spent on design and testing. I've worked on some safety critical systems (ie where someone dies if your code is wrong) and coding was about 10% of the project. This might take a lot of joy out of being a programmer but it pays to get it right!
pithy comment
Any advice with that? Though from the looks of things, there isn't anyone that's going the right direction.
What skills would I need to develop to be more forward? Everyone just takes them for granted and looks at me funny when I try to explain that I don't have them and that I'm not even sure what they are exactly.
I can really recommend you the book "Software Estimation: Demystifying the Black Art" by Steve McConnell (the same guy from Code Complete).
He recommends that you create two or three estimates: the best case, the worst case and the expected case. Using three estimates will give you several advantages:
- you express the uncertainty in your estimate to your managers
- Using some simple statistics you can calculate a much more reliable overall estimate (the errors in individual estimates average out if you combine them into a larger estimate).
But most importantly, he claims that the single point estimate you and I have been giving is in fact the best-case estimate. If you read the book you'll see that it is guaranteed to be impossible to hit the targets we set based on those single-point best-case estimates.
Example:
In a website / database that tracks worker's peformance, they want to redefine what it means to "make an error"
Once it's broken down
Remember
All estimation methods are based on reducing the uncertainty, by splitting the problem in smaller pieces and getting a better understanding of each individual piece.
Problems can however be sliced in many ways. People commonly split the problem in smaller pieces using a work breakdown structure (WBS) that is either deliverable-centric or activity-centric or both. But you can also split the estimation method itself into an estimate and a calculation.
Let's say that your developers can do on average 15 lines of code per hour and that your programming language of choice needs 30 code lines per function point. You use one of the many available function point methods to estimate the work for feature X to 35 function points. Thus an average developer will require 70 man work hours to implement feature X. An experienced developer will need less time, while a trainee will need vastly more and also some handholding. This method requires that you find out the metrics for your company.
Also remember that your estimate is only an estimate, and you can adjust the quality i.e. certainty of the estimate. Sometimes a quick educated guess is sufficient, like when Mr. Sales Guy wonders whether feature X is large enough to affect the price of a project. Other times you must spend hours or days on analysing the problem from various viewpoints, e.g. when scoping and pricing a complete customer project.
--Bud
For research, there's no knowing in advance. Took, what, about 100 years to prove Fermat's Last Theorem? What if you've got to write an algorithm to solve a problem that you think may be in NP, but you don't know? Might take quite a while to come up with a proof that the problem is NP. Or you could skip the proof and just assume it is NP, but then can you come up with a reasonable approximation algorithm?
Even if you don't have to wrestle with those issues, it can still very hard to tell how long it will take to write software. One problem is that while you can guess how long it will take to write something from scratch, you don't know if you'll find some library or code that will save you weeks of effort. How long do you want to spend searching the Internet and digging through libraries? You may get lucky and find something fast, or you may search for weeks before finding anything, if there is anything to find. Easy to overlook that it might take more time to search than to inplement it yourself. A simple program could therefore take 4 hours to do, or 4 weeks, you just don't know. This isn't school where a professor can assign a well known and heavily studied programming problem to be due in 2 weeks or some such, and have a pretty good idea that is a reasonable amount of time.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Hi gang!
I don't know if anyone has mentioned "Function Points" analysis yet, but it is worth checking out. (But to me, it has more value when developing older style dumb terminal data entry systems.)
- TWR
The thing that can streach out a project time line is rolling Specs. (the Oh-By-The-Ways) When you give them a spec you will need to take a good amount of time using Photoshop/GIMP/MSPaint mocups of the interface, and show them how each interface is going to work and how it will process the data and store it. Then you need to spec out what you client says will be a constant feature or a feature they think will change. Have the speces signed off by management stating they agree with the specs and anything beyond that will extend the project scope and costs.
Now that you have the full specs which now are considered static. Now you can figure out how much time it will take you to do each project. Using you experience Shorter if you have done it before and you remember how you did it. Longer for parts you never did but you have a clear image on how to do it. And much longer for something you never did and Don't know how to do yet and requires some extra research. Code that is agreed to be static threwout the products life cycle normally takes less time then features that are more flexible. And don't underestimate the Human User Interface, HUI usually takes most of the time because that section is the area of greatest amount of errors.
When the project occures and the Oh-By-the-ways come up (There is almost no if about it) then you need to re-evualite your project plan and adjust the hours and have management resign off of it again, explaining who put in the request and why. This is the Save your Ass method where if you go over schedule of the origional plan you have paperwork to proove that it is not your fault but Bob in QA Department who sees what you have and it expands his imagation for new features so he want more. Plus with management knowing this they can make the final decision if it is worth putting it in or not.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Nobody was talking about "worth doing". The question is about feasibility, whether of doing the project at all, or coming up with an estimate of how long it would take.
I agree: break it up into small task, work on them incrementally. The company I work for has used this method successfully for 10 years.
I have been in the industry over 20 years and this is one of the more difficult questions to answer. For me, having worked in both development and management capacities, the most accurate answer that can be provided is "it depends".
Primarily, it depends on what you know. There are a number of techniques beyond the W.A.G. of developer's experience with the software at hand (a google search for "estimation techniques" turns up over 900,000 matches), and depending upon the circumstances one technique may be better suited than another. IMHO they all boil down to one simple fact: the more you know the more accurate an estimate can be. As a manager, you develop a feel for which of your developers pad their estimates and by how much. When the numbers seem high, it is usually because they don't have enough information to make a more reasonable "guess". As a developer you don't want to get caught short when your "rough estimate" turns into a schedule deadline, so you take into account all the things that are likely to come up.
For me, the best way to stay out of trouble is to offer a range in your estimates. The less you know the wider the range and vice versa. You can always qualify the range estimate based upon what you know. Other posts have suggested taking time to "get back to you with that estimate" and that is a very valid technique to "know more", thus reducing the range of your estimate. If you have reasonable management and business users, they will understand that an estimate is a "best guess given the information available" rather than a due date to be slapped on a schedule.
How to come up with accurate estimates, isn't an easy question to answer. If it were, there would be one or two simple ways to do it accurately, and everyone would be following those procedures to come up with estimates.
FWIW...
I've done the math, I know the odds, but I'm still disappointed when I don't win the lottery.
Nothing beats experience on estimates, but, there are a few things I do on my calculations:
1. I assume that a rookie is doing the coding.
2. Time for a high level specification for the user to review.
3. Time for the review.
4. Time for a detailed design where you specify the low level rules for the coder.
5. Time for a review of the detailed design.
6. Time to write a document on how you will test, what you will test and under what conditions the code will pass.
7. Time to set up a testing environment.
8. Time to set up a Client acceptance test environment.
9. Time to write a document on the client acceptance environment, test conditions and under what conditions the client should sign off on the code.
10. Time to walk the client through the CAT document.
11. Time to walk through the CAT results.
12. Time to document how the code will be released, who is to be informed, what resources required, etc.
13. Time to walkthrough the release doc.
14. Document everything, if the client wants a change it is easier to do it at the design stage. After that do a Change request and make sure the client knows what happens to time/effort and the schedule.
A few rule of thumbs I work with on hours ->
1. Every hour of any document = 1/4 day walkthrough with the client.
2. Every hour of code should require a minimum of 2 hours testing (simple code).
3. Time for designing tests and the documents = time required to code.
4. Every hour of walkthrough with the client = 1/4 hour doing the walkthrough report.
Panic now, beat the rush!
I just follow our established company standard for estimating projects. The boss tells me how long it is going to take, and I say "Yes Sir!"
My old software manager came up with an outstanding way of trying to estimate project completion for trying to tell upper management when something would be done.
He asked each of the software engineers how long it would take, based on their "gut" instincts.
Then he multiplied the figure by two and moved it to the next higher order of time. I.E. weeks become months, months become years. One time he asked us to estimate when we could get something accomplished and we told him two years. He cried for a little bit and went to upper management and said "Never, we can't get that done".
Surprisingly this turned out to be a very effective way for him to gague when things would actually get accomplished, and more often than not he was dead on correct. He also didn't let me in on his secret until just before he quit, but it has also helped me to make my own estimates for customers when I'm doing contract work now. I do the same thing where I make a preliminary estimate based on known issues and then apply the above rule to my own guess. I have (fortunately) been fairly accurate with my guesses at that point, even if it makes the customer angry with them insisting that it must be done in a shorter period of time.
I am appalled that even some of the most experienced programmers persist in
attempting to provide time-to-completion estimates, which do nothing but
perpetuate the notion that there is anything meaningful about them.
We would refuse to read tea leaves or to rely on the auras of ground monkey
bones as a basis of distilling concrete knowns from nondeterministic unknowns,
so why then do so many of us go along with self-referential approaches like
"break it into its component parts, then use little estimates to determine
a big estimate..."?
The only correct answer is and will always be "We will know how long it took
when it is done. If you are an experienced manager and you want an accurate
time, then find all comparable programming tasks that you have observed
programmers complete, and use that information yourself to predict the future.
Asking me to do that for you doesn't gain you any accuracy."
Please stop giving pointy haired bosses the illusion that estimating time-
to-completion of programming tasks is even possible.
then multiply it by 3! :(
30 seconds means 15 minutes.
10 minutes means 5 hours.
12 hours means 6 days.
14 days means 7 weeks.
8 weeks means 4 months.
6 months means 3 years.
* First Rule of Project Management: Divide estimate by two, and round up to next higher unit.
Divide and rule policy not only helps to understand the system better but helps in the estimate as well. Added to that if you assign the level of complexity for each tasks it will be help in providing better estimates. Assign the complexity levels to the atomic level of design as more difficult,hard,normal,easy and then assign appropriate times\days to each one of those. You can further decompose difficult tasks into easy ones to derive estimates.
You'll still be wrong, but the more experience you have in solving these types of problems, the less wrong you'll be. To do an estimate (not for coding, but for engineering design on existing work), I sketch out the solution, and then break it down into discrete tasks. I do smallish projects, so that's resonable amount of time to put in (one to two hours, tops, usually less than 1% of the design time). From rules of thumb, I can assign an average value for each task type - usually only three or four type on any project - and get a good estimate.
For pure analyis work, I've got another benchmark. I can size up a job pretty quickly by eye based on experience and get the number of hours it will take to do the job if I am perfectly efficient, don't run in to any issues, and could work straight through. If I double that number, that's a good shot at the actual calendar time it will take. If there are others working on the project, I tack on 30% for changes which will require rework. It's scarily accurate, but only for from-scratch stuff; working on an existing system means method one, above.
Is it just my observation, or are there way too many stupid people in the world?