How long did it take to jump to the last new platform? How long for the last new API, last new language, framework, library?
If you had historical data on how things went the last time you did these things, you'd be better positioned to estimate how long it will take this time.
At some point, everything is similar to something you've done before. The difficulty is relating what you're doing now to what you did before.
If you go into it assuming that your work is some special snowflake that is completely novel in all respects, you'll get nothing out of it. Find parallels with what you've done before and you can actually make an estimate that's an improvement over a SWAG.
Guessing this won't be a popular response, but all the hand-wringing about how management is unreasonable to ask for estimates (cost or time) just isn't helpful.
Anything a business is going to invest in needs some kind of justification, and a metric to prioritize against other things the funds could be spent on.
I think it's fair to push back with suggestions that might make a realistic estimate possible (reduce scope, proof of concept, etc). However, just suggesting you can't provide any kind of reasonable time and cost estimate doesn't help anyone.
Reduction in scope and prototyping can help reduce risk in how wrong your estimate is, but I think it is misleading to suggest that these techniques inherently "might make a realistic estimate possible." I don't think I'm alone in that I've had tasks that were supposed to take less than a day take weeks. I'm not saying this is common, but there is no silver bullet, and assuming from the beginning that estimating is basically impossible can help bring everyone into reality.
It is for some companies. Or just do very crude estimates like "this might take 3-5 weeks" even for things that might take 1 week but could take 6 weeks.
Sometimes it is better to start developing and then tell stakeholders that it will take a really long time when you run into problems. A lot of stakeholders have problems with estimates of the form "it could take 2 days or 3 weeks". It would be nice if the industri starts giving probability about estimates especially when you know that there are two clear possibillties where one is much, much larger. They might want to invest 2 days into trying to solve the problem with the understanding that it might take much more time and if that happens they can change their mind and skip the feature instead, "only" wasting two days of investigation.
You can commit to an investment with no idea, at all, whether it will cost more than the benefit it delivers. I suppose "not an option" isn't quite the right wording. It's an option.
That's not what it means. You have to be diligent in asking properly and vetting the rules for what's to be done. It may also include gate meeting type things and regular status reporting. You just don't downshift the project into high torque when some phony date rises up.
I don't remember if it's "Mythical Man Month" or Thomas deMarco where I'd read it. They're better at explaining it than I.
But it's temporary state that will affect behavior and make things permanently worse - not just for the developer, but for everybody. Getting it wrong can inflict mortal blows on the enterprise. Having the power players escalate based on status will make it oh so much worse.
People need to understand that there is no zero-cost instrumentation and getting measurement wrong is extremely expensive.
I have to work backwards from deployment to development or there are problems. Sometimes there are external lags of months between them. People find my line of questioning in this regard very annoying but I do this and others on the team/teams do not, and I have a much better accuracy rate. So they've learned to do this with me.
When you're deploying, you're designing a protocol and that's always a challenge. But if you don't do it, the error rate creeps up.
I publish a statement of work for each release point and encourage redlines to that. So far it's not drawn any fire. But inadvertently getting a feature in before it's handed off properly causes lots of problems.
I still think you need some kind of estimate. At the very least, you should have a high level of confidence that "what I'm spending to get this" is less than "what value it will deliver".
Of course, if you can't be more precise than that, chances are that there's some other piece of work that's more easily estimated, and has a more concrete ROI. That work would logically come first.
Here's the problem. Management is going to make decisions. That's part of their job. They aren't psychic. As you say, you need some kind of an estimate (or at least, management needs you to give them one).
But there are times when you don't know. So you handle that by saying something like "I don't know enough now to give you any kind of an estimate. In a month, I'll be able to do enough research that I can give you a realistic estimate." If management will accept that, congratulations! You have management that is willing to live in the real world.
But you can't even always do that. I was asked to estimate how long it would take to port something I'd never had to touch before. Well, I don't know. Worse, I don't know how long it will take me to find out, because I don't know how many obstacles I'm going to hit, or how long it takes to get past each obstacle. I'll know when I'm done; I don't know any more precisely than that. I mean, I can say something like "probably less than a year", but I have no idea how to do better in that situation.
I agree that businesses need estimates, but the problem is the form they take. It's always "2 weeks", or maybe at a better place it'll be "2-3 weeks" both of which are basically lies because they imply high confidence. What it really ought to be is "2 to 3 weeks with X% confidence" because there's an absolutely massive difference between "2 to 3 weeks at 90% confidence" and "2 to 3 weeks at 10% confidence and at every place I've ever worked they both get treated the same. The 10% confidence one might be roughly equivalent to "2 weeks to 6 months" with an implied high confidence but good luck giving an estimate with that kind of range.
That seems completely reasonable, and provides what a business would want...metrics to make decisions on where to spend money.
The tack of the article was "Estimates can't be done". Which is silly. It presents this analogy: "would it really have made sense to ask Einstein how long he would take to find a unified theory of physics?"
I'm sure there's some small amount of software work that might fit in that space. I would also guess that the vast majority of it doesn't.
Yeah, I find the optimal balance between simple numbers that find traction politically, and the realistic but unpopular acceptance that things are uncertain is a triangular distribution "least possible, greatest possible, most likely".
You can plug these into monte carlo simulations with any kind of math happening between your uncertain terms, get output distributions, pick bounds to minimise risk (95% chance the release is completed on or before <DATE>).
It is generally the truth, though. I can't tell you how long it will take, because I don't know, because I've never done it before.
If I've done it before, or something enough like it that I actually could tell you how long it would take, then you are wasting your money and my time by asking me to repeat the work.
If you hired me because you wanted me to do the same thing for you that I once did for someone else, and you therefore expect me to be able to tell you how long it is going to take, then I will start polishing up my resume, because I made a mistake when I accepted your offer.
What I'm saying is that it doesn't matter if it's a software project, construction project, etc. If the potential amount is non-trivial, it's bad business to commit to a completely unknown amount of spend.
If you can't say that the spend < benefit, you really shouldn't do the work. It's basically speculative investment at that point.
That may be something you personally aren't on the hook for. But, in most cases, there's some option to get an idea. Bids from outside software development shops, calls to companies you partner with, small scale prototype, agreement to spend a fixed amount and re-evaluate, etc.
It very much does matter if it's a software project or a construction project, because the essence of a software project is that it involves an exploration into the unknown. If it were a routine process which could be estimated accurately, we'd have automated it already, and we wouldn't need to estimate it because we'd simply delegate it to a machine.
Software is nothing like construction. We don't build bridges, we draw blueprints for bridges, which our construction robots then build overnight; if it's a good bridge, millions of other construction robots go build millions more bridges just like it. If the bridge doesn't work, we have the construction robots tear it apart, and we try again with another one the next day.
When we get good enough at designing bridges that we start to see the patterns involved, we build a robot that draws bridge blueprints, and we have the blueprint robot tell the construction robots what to do while we sit around and think about urban design theory. When we get good enough at thinking about where bridges ought to be placed and what attributes they ought to have, we build ourselves a highway-design robot that orders around the bridge-blueprint robot that orders around the construction robots, and then we move on and start thinking about something more interesting.
Software is basically speculative investment. That is why we make the big bucks when our projects succeed.
edit: fwiw, construction projects often touch on "exploration into the unknown".
Also, you are arguing against "accurate estimation". I'm arguing against the premise of the article. "No kind of estimation is possible"
Edit. Nobody is asking for made up numbers. They are typically asking that engineers participate in a reasonable discussion to try and get some criteria to make a decision. "I couldn't even say 1 week vs 10 years" is just as silly as "I want an exact number".
Sure, and to the degree that they do, they can't be accurately estimated either.
... Even if the words people are saying sound like "We want to build this; how long will it take?", the process which actually happens is "We have this much money/time, and we want to solve this problem; what can we build in the time available?" To the degree that people believe they are operating in the former mode, sadness happens, because software engineering is actually about the latter.
Well, okay, sure, if you want me to make some numbers up, I can do that. Just understand that you're not actually asking me to estimate the time a process will take, you're asking me to make some numbers up so that you can convince yourself to feel good about the speculative investment you're making!
Edit: we've apparently had different experiences around the word "estimate"; for me that's always been a term used by managers who want something they can slot into a Gantt chart or its equivalent, and trying to play along with that game has always led to frustration. The people in my experience who have been looking for "some criteria to make a decision" haven't generally called the information they're looking for an "estimate". The processes which have actually worked, in my experience, don't start with tasks and try to generate a schedule which fits: instead, the process starts with a schedule, and the engineer's job is to figure out what can be done in the time available and how most effectively to make progress within that framework.
Even more so, there is an analogy to construction in software, and it has been possible to fully automate it since decades with tools like make, ant, etc.
Still, some projects will take longer than others, and it's possible to distinguish a 2-week project from a 2-quarter project, even if they actually end up taking 3 weeks and 3 quarters.
I feel like comparative sizing is the most important part of software estimates, so that you can make reasonable tradeoffs, e.g. "if we take on this project, we can't do these other 2 smaller projects". This is still a valuable exercise, even if all of the estimates are each individually quite inaccurate.
I agree completely. It's the only way I've found that works. Start the estimate by saying "these rolled-up, roughly estimated tasks come to about a year in total."
Now we know it's closer to a year than to two months. Once we start, we can continuously refine the estimate. "Sorry, there's a bunch of stuff we didn't see. We can give you X functionality in a year, or all of it if you can wait 18 months"
Lather, rinse, repeat. With experience and good time tracking of tasks, you learn how long things take: "every database we set up in the last year took about 10 days to get right." Now you know your estimate to configure a database and get it online is 10 days, not the optimistic "I can do it in an afternoon" that everyone claims.
The key to good estimating is good historical data. Problem is devs hate tracking their time and reporting accurately.
Trying to prove the impossibility of something that is never going to go away as a requirement isn't very useful.
An alternative would be to describe potential break-points and conditionals in the planning process. For instance, if a third party library can help you with some core functionality, it takes a few hours to investigate and an hour to implement.
But if it's not going to work for whatever reason, then you know you have to make your own, and the initial implementation could range from 4-6 weeks.
If you say "this will take either 4 hours or 4-6 weeks", that's far more useful and acceptable to management than saying "this will take somewhere between 4 hours and 6 weeks.
No one sane is asking for exact estimates, and no one smart is promising a hard deadline based on the assumption that nothing goes wrong. A good engineer will pad their estimate slightly for the same reason that airplanes carry more fuel than the exact amount they need to reach their destination. It's not a deceptive or inefficient practice, it's managing uncertainty.
No one sane is asking for exact estimates … It's not a deceptive or inefficient practice, it's managing uncertainty.
Part of the issue is that the asking for estimates ends up getting turned into exacting time requirements as an attempt to control and manage uncertainty. And often, many of the people who turn estimates into requirements are, arguably, insane, because they are trying to manage the uncertainty in the wrong way.
I've taken to just telling my boss whether I think something is 'just work', 'tricky' or 'hard'. And about howm much of that he's asking for,
Just Work: Means are the pieces are there to do whats wanted.
Tricky: Means I need to create something from scratch or modify two or more modules.
Hard: Anything to do with timing, interrupts, or that involves re-organizing swaths of unrelated code.
Hard2: I have to learn a new language, frame-work, microprocessor, etc.
Companies have budgets so estimates are necessary. Volunteer or work in open source if you don't like it. Those asking - business types usually - know (and often care) little about the craft, so they can't be expected to be much help.
The best you can do is be experienced enough to be able to get it somewhat close. Nothing wrong with padding. How much.. is an art form. But remember technical people nine times out of ten, will under-estimate.
1) it seems that the accuracy of an estimate is inversely proportional the length of time for which it applies. In my experience engineers aren't too bad at estimating if a task can plausibly fit into a two week sprint
2) I think the boss should be taking an active part in the estimation process, not just asking "how many hours/days".
When I estimate with my teams I try to say "given x,y,z and the current state and that A,B,C blocks are not quite understood can this item reasonably be completed within our sprint"
..then we play poker / vote / comment etc. If the item isn't plausible for a sprint I'm (likeaboss) going back to the drawing board on that item to define it better and get it into more manageable pieces (consulting the team as needed)
We're striving to make sure work items are defined well enough to be fairly confident they can be done in a short amount of time.
33 comments
[ 2.8 ms ] story [ 73.1 ms ] threadIf you had historical data on how things went the last time you did these things, you'd be better positioned to estimate how long it will take this time.
If you go into it assuming that your work is some special snowflake that is completely novel in all respects, you'll get nothing out of it. Find parallels with what you've done before and you can actually make an estimate that's an improvement over a SWAG.
Anything a business is going to invest in needs some kind of justification, and a metric to prioritize against other things the funds could be spent on.
I think it's fair to push back with suggestions that might make a realistic estimate possible (reduce scope, proof of concept, etc). However, just suggesting you can't provide any kind of reasonable time and cost estimate doesn't help anyone.
The essence of my point was that flat out not estimating isn't an option.
Sometimes it is better to start developing and then tell stakeholders that it will take a really long time when you run into problems. A lot of stakeholders have problems with estimates of the form "it could take 2 days or 3 weeks". It would be nice if the industri starts giving probability about estimates especially when you know that there are two clear possibillties where one is much, much larger. They might want to invest 2 days into trying to solve the problem with the understanding that it might take much more time and if that happens they can change their mind and skip the feature instead, "only" wasting two days of investigation.
I don't remember if it's "Mythical Man Month" or Thomas deMarco where I'd read it. They're better at explaining it than I.
People need to understand that there is no zero-cost instrumentation and getting measurement wrong is extremely expensive.
I have to work backwards from deployment to development or there are problems. Sometimes there are external lags of months between them. People find my line of questioning in this regard very annoying but I do this and others on the team/teams do not, and I have a much better accuracy rate. So they've learned to do this with me.
When you're deploying, you're designing a protocol and that's always a challenge. But if you don't do it, the error rate creeps up.
I publish a statement of work for each release point and encourage redlines to that. So far it's not drawn any fire. But inadvertently getting a feature in before it's handed off properly causes lots of problems.
The critical resource is always human attention.
Of course, if you can't be more precise than that, chances are that there's some other piece of work that's more easily estimated, and has a more concrete ROI. That work would logically come first.
But there are times when you don't know. So you handle that by saying something like "I don't know enough now to give you any kind of an estimate. In a month, I'll be able to do enough research that I can give you a realistic estimate." If management will accept that, congratulations! You have management that is willing to live in the real world.
But you can't even always do that. I was asked to estimate how long it would take to port something I'd never had to touch before. Well, I don't know. Worse, I don't know how long it will take me to find out, because I don't know how many obstacles I'm going to hit, or how long it takes to get past each obstacle. I'll know when I'm done; I don't know any more precisely than that. I mean, I can say something like "probably less than a year", but I have no idea how to do better in that situation.
The tack of the article was "Estimates can't be done". Which is silly. It presents this analogy: "would it really have made sense to ask Einstein how long he would take to find a unified theory of physics?"
I'm sure there's some small amount of software work that might fit in that space. I would also guess that the vast majority of it doesn't.
You can plug these into monte carlo simulations with any kind of math happening between your uncertain terms, get output distributions, pick bounds to minimise risk (95% chance the release is completed on or before <DATE>).
If I've done it before, or something enough like it that I actually could tell you how long it would take, then you are wasting your money and my time by asking me to repeat the work.
If you hired me because you wanted me to do the same thing for you that I once did for someone else, and you therefore expect me to be able to tell you how long it is going to take, then I will start polishing up my resume, because I made a mistake when I accepted your offer.
What I'm saying is that it doesn't matter if it's a software project, construction project, etc. If the potential amount is non-trivial, it's bad business to commit to a completely unknown amount of spend.
If you can't say that the spend < benefit, you really shouldn't do the work. It's basically speculative investment at that point.
That may be something you personally aren't on the hook for. But, in most cases, there's some option to get an idea. Bids from outside software development shops, calls to companies you partner with, small scale prototype, agreement to spend a fixed amount and re-evaluate, etc.
Software is nothing like construction. We don't build bridges, we draw blueprints for bridges, which our construction robots then build overnight; if it's a good bridge, millions of other construction robots go build millions more bridges just like it. If the bridge doesn't work, we have the construction robots tear it apart, and we try again with another one the next day.
When we get good enough at designing bridges that we start to see the patterns involved, we build a robot that draws bridge blueprints, and we have the blueprint robot tell the construction robots what to do while we sit around and think about urban design theory. When we get good enough at thinking about where bridges ought to be placed and what attributes they ought to have, we build ourselves a highway-design robot that orders around the bridge-blueprint robot that orders around the construction robots, and then we move on and start thinking about something more interesting.
Software is basically speculative investment. That is why we make the big bucks when our projects succeed.
edit: fwiw, construction projects often touch on "exploration into the unknown".
Also, you are arguing against "accurate estimation". I'm arguing against the premise of the article. "No kind of estimation is possible"
Edit. Nobody is asking for made up numbers. They are typically asking that engineers participate in a reasonable discussion to try and get some criteria to make a decision. "I couldn't even say 1 week vs 10 years" is just as silly as "I want an exact number".
... Even if the words people are saying sound like "We want to build this; how long will it take?", the process which actually happens is "We have this much money/time, and we want to solve this problem; what can we build in the time available?" To the degree that people believe they are operating in the former mode, sadness happens, because software engineering is actually about the latter.
Edit: we've apparently had different experiences around the word "estimate"; for me that's always been a term used by managers who want something they can slot into a Gantt chart or its equivalent, and trying to play along with that game has always led to frustration. The people in my experience who have been looking for "some criteria to make a decision" haven't generally called the information they're looking for an "estimate". The processes which have actually worked, in my experience, don't start with tasks and try to generate a schedule which fits: instead, the process starts with a schedule, and the engineer's job is to figure out what can be done in the time available and how most effectively to make progress within that framework.
I feel like comparative sizing is the most important part of software estimates, so that you can make reasonable tradeoffs, e.g. "if we take on this project, we can't do these other 2 smaller projects". This is still a valuable exercise, even if all of the estimates are each individually quite inaccurate.
Now we know it's closer to a year than to two months. Once we start, we can continuously refine the estimate. "Sorry, there's a bunch of stuff we didn't see. We can give you X functionality in a year, or all of it if you can wait 18 months"
Lather, rinse, repeat. With experience and good time tracking of tasks, you learn how long things take: "every database we set up in the last year took about 10 days to get right." Now you know your estimate to configure a database and get it online is 10 days, not the optimistic "I can do it in an afternoon" that everyone claims.
The key to good estimating is good historical data. Problem is devs hate tracking their time and reporting accurately.
An alternative would be to describe potential break-points and conditionals in the planning process. For instance, if a third party library can help you with some core functionality, it takes a few hours to investigate and an hour to implement.
But if it's not going to work for whatever reason, then you know you have to make your own, and the initial implementation could range from 4-6 weeks.
If you say "this will take either 4 hours or 4-6 weeks", that's far more useful and acceptable to management than saying "this will take somewhere between 4 hours and 6 weeks.
No one sane is asking for exact estimates, and no one smart is promising a hard deadline based on the assumption that nothing goes wrong. A good engineer will pad their estimate slightly for the same reason that airplanes carry more fuel than the exact amount they need to reach their destination. It's not a deceptive or inefficient practice, it's managing uncertainty.
Part of the issue is that the asking for estimates ends up getting turned into exacting time requirements as an attempt to control and manage uncertainty. And often, many of the people who turn estimates into requirements are, arguably, insane, because they are trying to manage the uncertainty in the wrong way.
Just Work: Means are the pieces are there to do whats wanted. Tricky: Means I need to create something from scratch or modify two or more modules. Hard: Anything to do with timing, interrupts, or that involves re-organizing swaths of unrelated code. Hard2: I have to learn a new language, frame-work, microprocessor, etc.
The best you can do is be experienced enough to be able to get it somewhat close. Nothing wrong with padding. How much.. is an art form. But remember technical people nine times out of ten, will under-estimate.
1) it seems that the accuracy of an estimate is inversely proportional the length of time for which it applies. In my experience engineers aren't too bad at estimating if a task can plausibly fit into a two week sprint
2) I think the boss should be taking an active part in the estimation process, not just asking "how many hours/days".
When I estimate with my teams I try to say "given x,y,z and the current state and that A,B,C blocks are not quite understood can this item reasonably be completed within our sprint"
..then we play poker / vote / comment etc. If the item isn't plausible for a sprint I'm (likeaboss) going back to the drawing board on that item to define it better and get it into more manageable pieces (consulting the team as needed)
We're striving to make sure work items are defined well enough to be fairly confident they can be done in a short amount of time.
"How long will it take to add a feature to frobulate the fribbers?"
"What's a fribber, and what, exactly, does it mean to frobulate them?"
Handwave "How long? We need to schedule this."
"Can I do some research about frobulating fribbers and how one goes about doing that?"
"No, we need an estimate"
"Ok, five minutes? Six weeks? Six years? Who the hell knows? What do you want me to say?"