71–80 of 212 posts
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
The real problem is not with estimation but with the management denial. I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.” Two years la…
Time estimations are bargaining, you ask for something and then get a counter offer from management, they don't care that the counter offer from them is delusional. The bargaining is the point, the less time you bargain for the more stressful the development can become. Don't estimate what it should take, estimate what it could take and bargain from there.
Earlier quoted context omitted.
the map becomes the territory here. if you have enough information to accurately estimate a project then you've already done the bulk of the work, and all you have left to do is type. The reason estimates are hard is because the work surprises you. You find out there are problems you didn't expect that must be solved to meet the stated goals. This happens all the time, it always happens on anything non trivial, which…
> if you have enough information to accurately estimate a project then you've already done the bulk of the work This is false. I’ve learnt 10s of new UX frameworks in my career and it takes about 20 hours from scratch to become proficient enough in one to design a new complex widget in it (say) — but knowing that doesn’t suddenly absolve me from spending those 20 hours.
I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. On the other hand you have engineers, who either explicitly or implicitly understand th…
If both sides agree that any estimation is a wild guess made with many assumptions, then you can go from there. Of course that means planning is difficult, but knowing that your plans need adaption is far superior to be in denial about it.
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
Many, many moons ago I asked my mentor how to estimate. He told me that you should figure out what it feels like, then double it and then take it to the next higher time unit. "hmm, adding that button probably takes about an hour"... 2 days is about right. Almost 30 years later I still find this to be true. Truer than I like.
Why do software people think they're special? Like it's somehow expected that we can predict everything because we're computer geniuses? We would have accurate estimates if only we "scienced" better? If you want to get very good at estimation, do it for a very long time. Then you will see how your estimates would be very accurate if all the other things in the world didn't happen. Just let go of the idea that you wil…
Some industries are pretty good at estimating effort. Eg when a film crew shoots, they have so many weeks, and they usually manage to shoot the footage for the movie within that time.
For instance if you had a clear unambiguous spec of what the the software must do, you could give it to 10 different teams and measure how long each took.
If you then modify the spec even slightly you could make it impossible to create such a program no matter how long you work on it.
But every project has its own different spec. We don't know how long it will take until we try to do it at least once.
Researches might study how long it takes on average to implement a given specific spec by different teams. But they can not estimate how much it would take to implement any arbitrary spec because - nobody has every tried to implement that spec before. And studying that tells you very little about how much time and effort is needed to implement any other arbitrary spec.
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
Many, many moons ago I asked my mentor how to estimate. He told me that you should figure out what it feels like, then double it and then take it to the next higher time unit. "hmm, adding that button probably takes about an hour"... 2 days is about right. Almost 30 years later I still find this to be true. Truer than I like.
You don’t want them interacting with you too often for one hour tasks. You want to train them to lower resolutions slices. And you want to round up small ones to do refactoring as well.
Eventually they get a sense of just right. It’s never perfect but they are estimating before they even ask. Whic if we’re honest, they’ve done anyway and they’re hoping we will agree, absolving them of the responsibility.
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
Earlier quoted context omitted.
Many, many moons ago I asked my mentor how to estimate. He told me that you should figure out what it feels like, then double it and then take it to the next higher time unit. "hmm, adding that button probably takes about an hour"... 2 days is about right. Almost 30 years later I still find this to be true. Truer than I like.
So 1 Month becomes 2 years? I don't think that's a good rule.
And if you're estimating something to the lengths of months, you're already into project management territory size, rather than broken down to development/delivery sizes... The amount of unknown unknowns and other uncertainty certainly warrant happily estimating years length, surely.
Also #NoEstimates (=