You Can't Do Software Estimates at All
chrismm.com
chrismm.com
"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?"
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.
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.
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.
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.
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.