111–120 of 212 posts
Earlier quoted context omitted.
> There’s a theory that work expands to fill the time you give it https://en.m.wikipedia.org/wiki/Parkinson's_law
It can also just barely squeeze into the time you give it, by the skin of your teeth.
Earlier quoted context omitted.
In this case why not just divide the estimate by the confidence to get the "true estimate" e.g in your example it's actually a 4 week. If you provide a tuple the confidence will eventually be conveniently dropped in some slide deck then the "2 weeks" will be socialised as the commitment.
The estimate-confidence relation is not linear. In my experience it follows some kind of S-curve, with 0% confidence approaching impossibly short times and 100% approaching infinity (like a logistic function).
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…
I know you like to complain alot about how your cubicle roommate doesn't understand basic control structures and the difference between floating point and integers, but he, unlike you, always adds story points to the tickets. That's why he's on fast track to lead senior developer. He knows what's important. I'm trying to help you learn what's important too, but you've got to want to be helped.
My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…
> We are building Sydney Opera Houses. Sorry, this made me laugh. I know there are software engineers which build clean and polished beautiful mega structures. I _aspire_ to that. Yet that is a niche market. In reality, most devs are making unique family Vilas at best. I wish I could ever say I feel like I contributed to an equivalent of 'Sydney Opera House'.
There are deep analysis from the project management perspective but one point was that initial estimates were based on historical assumptions while some elements were novel and couldn’t be estimated with those techniques.
With software it’s similar. We have some general feel how things should work but often there’s “this” novel part that no one did before and it’s wishful thinking, leading to budget and timeline spillover.
If you ever had to guess-estimate something you never saw and it turned out to be overly optimistic - that’s similar case to Sydney Opera House (which I recommend to read about as there are many analyses of the case from various project-related points)
Earlier quoted context omitted.
I don't disagree with you but I think people also need to understand that management often pick the team that provides lower estimates because team members will have to work harder to deliver it. Management might not be so dumb. If someone said 2 months and you say 6 months, they might go with the person who said 2 months but will accept 5 months secretly.
In my experience the 2 month version is so bad it’s still being hotfixed in production in month 8.
The 2 month version could be sold at all, the 6 month one can't, so it's not worth considering its technical merits.
Then the client/stakeholder buys in, the sunk cost, well, sinks in, and things get fixed. Success!
Earlier quoted context omitted.
In this case why not just divide the estimate by the confidence to get the "true estimate" e.g in your example it's actually a 4 week. If you provide a tuple the confidence will eventually be conveniently dropped in some slide deck then the "2 weeks" will be socialised as the commitment.
The estimate-confidence relation is not linear. In my experience it follows some kind of S-curve, with 0% confidence approaching impossibly short times and 100% approaching infinity (like a logistic function).
A bad estimate is better than no estimates at all. There are plenty of empirical studies that prove that. Some computer scientists have a hard time dealing with non mathematical proofs. They have a huge blind spot for things like empirical case studies, qualitative studies, etc. Those are tools that people in other fields use when mathematical models fall short. There are not a lot of useful mathematical models you c…
Earlier quoted context omitted.
The estimate-confidence relation is not linear. In my experience it follows some kind of S-curve, with 0% confidence approaching impossibly short times and 100% approaching infinity (like a logistic function).
The logistic function is bounded, so I'm not sure what you mean...
Earlier quoted context omitted.
The estimate-confidence relation is not linear. In my experience it follows some kind of S-curve, with 0% confidence approaching impossibly short times and 100% approaching infinity (like a logistic function).
I think software projects are best estimated as gamma distributions. To express that as confidence levels, you use the cumulative distribution function of the gamma, which are kind of S shaped, but stretched to the right. https://en.wikipedia.org/wiki/Gamma_distribution
https://www.wolframalpha.com/input?i=gamma+distribution+with...
And the confidence distribution would be:
https://www.wolframalpha.com/input?i=cumulative+gamma+distri...
My conclusion is there are 2 kinds of engineer: good ones and shit ones. Good ones just need to be told what to do and be left to get on with it. They value autonomy, and any attempt to micromanage them with agile bullshit drastically demotivates them. Shit ones are shit. They need a good one to help them get through their tickets, by asking what's taking so long and showing them better ways of approaching the proble…
Granted this was just my very limited experience, and we didn’t spend much time on estimating and standups consisted of a scheduled daily Slack ping instead of a meeting since we had major timezone offsets. People over process and all that.