I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate.
And when road blocks come up just communicate early, and then if PM/boss don't understand there is not much you can do but probably look for a better gig.
Great! Please let us know when cancer will be cured.
In other words, "I don't know" is sometimes a complete answer. I don't know. Period.
This is supposedly one of the main points of this religion (agile). Some things are unknowable. So you move ahead a bit, and reassess. If you are scrumming, that is usually 2-3 weeks, and don't get me started on that arbitrary limit. But, you try to move forward for a bit, learn something, and then that might
1) let you know enough to know how to estimate
2) give you some information on what not to try next (I tried a, b, and c, and they all failed)
3) give you guidance on what to work on next (d seems promising, I can flesh it out more and see if it still seems like a promising avenue).
You proceed on, and eventually get your hands around the problem, or the person writing checks decides this is not an economical search (because that is what this is, search on a multidimensional surface) and change/delete the requirement.
That's what agile is supposed to be, with a nod to the fact that yes, we can estimate writing a single database query or something fairly well, so in some cases estimates can be useful at this scale.
The bane of my existence is the endless pressure for estimates. I'm doing research; no one has done this stuff before. It is truly unknowable. If it was known it would be in a paper somewhere, and I would merely be implementing that paper. So I get told "break it down into smaller chunks", as if my 30 years of success didn't teach me how to break down problems. Thanks PM that has never coded or produced anything intellectually novel before! I'm surely being dumb and/or obstinate!
I got that written in my previous performance review, that I don't know how to plan and break down problems, because I flatly refuse to play this game. You get punished for trying for hard things. It's nonsense. "I don't know" cannot be changed by insisting on an estimate.
Insisting on the estimate in that situation is basically a special case of the old trope of using something meaningless but easy-to-measure as a proxy for something important but hard-to-measure. It's hard to know how long something will take, and easy to ask someone how long they think it will take (or if it's you, to pull an estimate out of your butt).
An absurd comparison given most software engineering tasks have been done before, they're simply difficult to estimate for some given team without expertise in doing some particular task.
>I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate.
This isn't personal, just a comment on a way of thinking that is not uncommon: each of those sentences are insane and not based in reality. You may "feel" these things are possible, but that's about as far as it goes. "Just look up all the unknown stuff." OK.
I wish people were more comfortable saying "I don't know but I can do some research and get back to you later." Often times that's where the conversation about time estimates ends because they don't ask you again unless it's actually important. And if they do ask you, now you have a better answer (assuming you actually looked into the problem you're trying to solve).
The other problem with time estimates that I find is that even though I might know for sure that a certain feature will take only a day or two, I can't tell when it'll be done because I usually have other things to work on as well.
Well here's the thing. Often I'm asked for my estimate in the same meeting I first see the story. I have no way of researching before giving an estimate.
> ... and then if PM/boss don't understand there is not much you can do but probably look for a better gig.
> Often I'm asked for my estimate in the same meeting I first see the story
That's definitely awful. Personally when I was leading agile teams, for anything non-trivial we'd start by creating an issue to scope the individual parts of the project, frequently allocating several days to do so.
And some stuff is still mostly unscoppable. That's where Fermi estimation and the whole "How many chips can you fit in the empire state building" time deal comes into play. You have no way to really know how long something will take, but we need to allocate resources SOMEHOW, even if its completely off. An imperfect guesstimate is better than none at all.
The catch is that everyone involved has to know that its an imperfect (and potentially completely wrong) guesstimate, and it has to be revisited regularly as new information comes in. Everyone also has to be ok with restructuring the project (or even cancelling it, in extreme cases!) if we learn its completely wrong.
We recently discovered at work that an assumption/decision that was made nearly 2 years ago turned out to be totally false. The project that relied on that false assumption was about 10% in (the assumption was made long ago, but actually work started recently). We had to sit together and ask ourselves if it was actually worth pushing through the 90% (and likely regret it in a year), or agree to scrap the 10% and start over now that we know what we're doing. We have to be careful not to pull off a Vista/WinFS resource blackhole though!
I used to think that too, but is it really? If estimates are always wrong, then is there really much of a difference? Besides, the lead often has business related information that informs his decision of "this feature must take no longer than X amount of time or we're going to have problems with Y" where Y is often political and not technical.
I remember when Agile development used to involve chickens and pigs. If you have no idea what I'm talking about, then you're not doing Agile as it was written. Almost nobody is today.
I don't agree with you - you're presenting the view which is the exact position people here are trying to put words to why doesn't work (and often hate about their jobs).
But downvoting you is just as counterproductive as burning the devil's advocate and you have my upvote. I hope people will get a hold of their emotions.
I've just spent a month doing a script I thought I could do in a weekend. I didn't realize several of the difficulties inherent in the data, I didn't realize I'd have to up my game with regard to techniques in shuffling data and I didn't know I'd run into so many quirks in the programming language.
I didn't know what I didn't know. That's why I guessed wrong.
In everything you haven't done before, you don't know what you don't know - and only a small portion of those things could have been realized by spending some hours researching the work I needed to do. Those didn't pop up on my radar until I had to solve them :(
But that knowledge isn't without value. Knowing that it is doing stuff you haven't done before that is risky (timewise) means you can underscore when you have a high-risk assignment.
Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%.
Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower.
I simply do not accept it is impossible to project a timeline for software. If someone stops you in the hall and says "hey you, how long will this take?" That is not a reasonable question, so sure you cant give a reasonable projection. If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous.
> Refueling nuclear aircraft carriers have projections start to finish, a half decade long.
The difference is that those projections weren't spit out on the fly by a engineer after a 15 minute pitch of some manager's great new idea. Those plans took many months of effort to put together by a team of specialists planning out the various details of the project. Software does have the equivalent of this, it's called waterfall development. The reason we don't do this is because, unlike aircraft carrier design, if you take six months to create a project plan your requirements will have likely already substantially changed.
I'm not a nuclear aircraft carrier refueller, so maybe the domain is different in a way I don't understand, but it's ridiculous to need a five year plan to just refuel something, people refuel cars in five minutes everyday.
I simply do not accept that it is impossible to refuel in a week or so, assuming it's a couple orders of magnitude more complex than refueling a car.
However, your comment didnt help me understand. It doesnt help because even if i embark on something i have no idea about, even in total ignorance i can _bound the problem_.
I dont understand how a professional coder can approach even a problem and have no idea - you have to DO the problem, so what is your approach? Just start coding and somewhere between 5 days and 5 years you stop?
Planning meetings dont happen in a vacuum, so what kind of problem can you research but have literally no guess about its solution? Bear in mind, we're not talking edge cases (research grants or whatever), but coders hired to do a job.
This is the nub of the problem when it comes to software. I understand your skepticism but software development is really very different from other activities. It is "mind-stuff" (and thus quite unstructured) which needs to be expressed in very precise language to solve an [almost always ill-defined/constantly redefined] problem. The inherent complexity involved is huge due to the number of degrees of freedom and malleability involved.
I can do no better than point you to the article "The Humble Programmer" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW...) written by one of the pioneers of Computer Science to really understand the issues that make Software Development such a complex and difficult activity. And since then (the article is from 70's) we have made matters exponentially worse by orders of magnitude.
The spell for floating an object is Wingardium Leviosa. It usually takes an 11-year old a few days to become proficient at it.
Please give an estimate for a modification of this spell that will make the object lift, complete two vertical circles (720 degrees) and then go back to the starting point.
(Before you ask: yes, we're doing magic. We're combining words in specific ways to create significant effects in the world.)
Software development is filled with fractals. To do A, you break it down into A1, A2, and A3. To do A1, you break it down into A1.1 and A1.2. To do A1.1, you break it down into A1.1.1 and A1.1.2.
In even a small project, that means that your moment-to-moment work might be something like "do task A4.1.2.3.5.3.2.1.5.4". Not literally, but conceptually, that's what's happening. Every task involves a bunch of other tasks, which involve a bunch of smaller tasks, ad infinitum.
This is probably similar to your refueling of a nuclear aircraft carrier. Big tasks involve little tasks, which involve smaller tasks. I assume. I've never refueled a nuclear aircraft carrier. But I have developed a lot of software.
Every software project is a working a plan that has never been done before. Because when it is done, the result is software that is infinitely reproducible, so there is no need to do it again. It's as if somebody needed to figure out how to refuel a nuclear aircraft carrier once. And then after that, everybody who wanted to refuel just cut-and-pasted a fully-fueled carrier.
In many ways, writing software is like figuring out that plan. It's not following the plan, it's creating the plan. And somebody who knows how to do A can figure out that involves A1, A2, and A3. And they can probably figure out that A1 involves A1.1 and A1.2. But they can't predict all the way to A2.3.1.5.2.4.2.2.5.1.1.1.5.2. (It's been tried. It didn't go well. Google "Software Crisis.") Too many issues don't appear until you try to solve them for real.
And those little edge tasks way down at the bottom? They might take five minutes. Or they might turn into another nested set of tasks that takes five hours. Just today, I was working with a team trying to solve a simple problem: print the URL of their current web page. This was no problem. The tool we were using to serve web pages told us the current URL. But it only told us the url's path (the part after the domain name). We also needed the scheme ("https:") and the domain name ("news.ycombinator.com") and the port (":80").
And that wasn't something our tool expected us to want [1]. So a five minute task turned into a half-day marathon of reading documentation, trying things, and reading more documentation. It took us half the day to figure out how to do something that should have taken us five minutes, and we had assumed it would only take five minutes when we estimated the larger task two weeks ago.
Coders who know professional estimating techniques approach this problem by using Monte Carlo simulations that provide a probabilistic range of dates. The high-confidence numbers resulting from these simulations are usually way too far in the future to satisfy stakeholders, because the simulations have a long tail. (More can go wrong than can go right.) Professionals have found it's often easier to refuse to provide estimates than to fight over high-confidence estimates or educate stakeholders in interpreting probabilistic date ranges. Not estimating saves lots of time, too.
I hope this long-winded explanation is the help you were looking for.
[1] For the nitpickers in the audience, I'm obviously leaving out a huge amount of detail about how our REST API was actually interacting with its framework. But that's the gist--we were trying to find a clean way to translate our current absolute URL to another absolute URL. Even now, I'm sure we were missing something obvious.
This is a much better explanation of the problem with estimates than my analogy :)
Especially this part:
Professionals have found it's often easier to refuse to provide estimates than to fight over high-confidence estimates or educate stakeholders in interpreting probabilistic date ranges. Not estimating saves lots of time, too.
Very true; to expand on this metaphor, past experience has lead me to ask “does this thing actually need fuel, or is it in fact a bicycle?”; aka: please give me the full context - what are you actually trying to achieve and why?
> If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous.
True, but it's because that question is often ridiculous.
If it's technology I've never worked with before, in a domain I've never worked, for which the test data doesn't exist yet, it's perfectly reasonable to be outside an order of magnitude.
E.g., we mostly do Web app development with React and Django, sometimes going into more complicated data processing and visualization. In a recent planning meeting we were asked about recognizing waterways from aerial photographs to improve local government's GIS datasets. Ummm...
> we mostly do Web app development with React and Django, sometimes going into more complicated data processing and visualization. In a recent planning meeting we were asked about recognizing waterways from aerial photographs to improve local government's GIS datasets. Ummm
To be fair, thats something that happens all the time in "normal engineering". While the field itself is much better understand (mostly because aside of record beating sky scrappers, its usually within the same problem space), not everyone knows everything.
For a more down to earth example, if I ask my carpenter to scope out a bathroom remodel, the first thing he's going to do is call a plumber to take a look. The carpenter's not going to be able to give an answer on the plumbing themselves, but they sure as hell can say "Im going to ask someone and get back to you on it".
As a software engineer, I have a network of connections I can reach out to if I'm asked about a problem completely out of my space, and you'd be hard pressed to ask about something that no one in my team knows or has a connection to someone who knows. Definitely won't get the answer today or even tomorrow, but we can get SOME information.
Refuelling a nuclear aircraft carrier may be a complex operation but it's one for which the plan was already developed quite some time ago.
To compare to software development is missing the point. Building a PC, installing Windows and all the apps you need might take half a day if you're experienced, and it'll take half a day each and every time: it's labour and you can't reduce the time taken to zero. That's like refuelling an aircraft carrier: executing a plan.
But software development isn't like manual labour where you execute a pre-determined plan. It's more like researching how to build the aircraft carrier. Once the plan (the software) is built, installing and executing it is trivial and takes very predictable amounts of time, which means software developers are almost always doing "research" even if it doesn't seem that way.
How long did the first nuclear aircraft carrier take to design? Well, literally the first sentence of the Design section of the wiki article for USS Enterprise says:
Enterprise was intended as the first of a class of six carriers, but massive increases in construction costs led to the remaining vessels being cancelled
So I guess ship designers suck at estimating about as much as software developers do.
One way software is different is that you're always doing things you've never done before. Because if you've done it before, you can just reuse that code.
This is probably not how the refueling nuclear aircraft carriers projects work.
That said, it's usually not quite as completely unknowable as your last sentence. Then again, it frequently is.
The real tension is about trust. When people think engineers are lying about their estimates.
"We have this problem, you see, where cells sometimes start to multiply aggressively instead of doing their job. That's a bug, the customers are complaining. How long will it take to fix it? What do you mean you don't know - not even a ballpark estimate?"
You refuse to accept that there's a possibility of something in a domain you have no understanding of... That sounds like a very illogical refutation in itself
Could you expound on this? I’m not saying I disagree, I’m just not sure which part of what he says disqualifies software engineering from being “engineering”
Start with the HUGE failure rate in software development. There is no provable reliability and/or costing, nor is there any form of standardization beyond RFCs and "best practices." One might even doubt that it's even possible for there to be standards like you see in capital-E Engineering due to the unique and complex nature of general computing systems.
To sum up, software development requires too much trust, way more than would be acceptible in an aircraft carrier or airplane or nuclear bomb. Or refrigerator.
Software engineering is clearly engineering. The main difference is simply that in the software world, engineers often report directly to people who aren't engineers. This basically never happens in other fields - e.g. all buildings, tunnels, railways etc are built by dedicated engineering firms founded and run by more engineers. The exception in software is of course the tech industry, which routinely pulls off engineering marvels.
Projects usually go wrong, or are "late" (relative to estimates engineers didn't want to give in the first place), when they're being closely controlled by people who are not engineers. The recent article on Berlin's new airport being a case in point, where the politicians tried to double its size after it started being constructed and the entire project collapsed in a heap.
Now imagine that happening all the time, every day. That's the enterprise software world.
And when road blocks come up just communicate early, and then if PM/boss don't understand there is not much you can do but probably look for a better gig.