111–120 of 237 posts
[1] https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
Earlier quoted context omitted.
> the first number you put out will be remembered This is called anchoring effect, a psychological bias.
I think you meant "anchoring bias": https://www.scribbr.com/research-bias/anchoring-bias/ Anchoring effect is something related but subltley different: https://en.m.wikipedia.org/wiki/Anchoring_effect
https://www.wikipedia.org/wiki/List_of_cognitive_biases#Anch...
and follow the first link labeled
Main article: Anchoring (cognitive bias)
Actually, you may also read the first link you sent and be equally surprised:
Anchoring bias (also known as anchoring heuristic or anchoring effect)
I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…
Reminds me of Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law. We could say, always say it will take longer than you think? Though by this principle, it seems that "overestimates" are likely to be actually accurate? Joel Spolsky wrote about his time estimation software which recorded the actual time required for completion, and then calculated for each person…
And Joel sidesteps the unknown-unknowns problem in that piece, by discussing boiling down tasks to But what if you need to build a prototype before you sufficiently understand the project and options to decide on an approach? Where does that time get estimated?
The more projects I work on, the bigger of a fan of spiral development [0] I become.
Because, at root, there are 2 independent variables that drive project scheduling -- remaining work and remaining risk.
This estimation problem would drastically simplify if it allowed for "high confidence, 30 days" and "low confidence, 5 days" estimates.
And critically, that could drive different development behavior! E.g. prototype out that unknown feature where most of the remaining technical risk is.
Trying to instead boil that down to an un-risk-quantified number produces all the weird behaviors we see discussed elsewhere in the comments.
Those dates were mostly informed guesses of what would actually happen or go wrong. Importantly this was between friends. Needless to say, they turned out very accurate.
Earlier quoted context omitted.
In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who…
So many bold claims in this comment and little to no justification. For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.
I have the same anecdotal experience with a possible explanation:
Inexperienced engineers often don't see the greater picture or the kind of edge cases that will probably need to be handled ahead of time. I've often had the following type of conversation:
Engineer: "I think that would be a day's work"
Me: "This will need to interact with team X's package. Have you accounted for time spent interacting with them?"
Engineer: "Oh no, I guess two days then"
Me: "Will this account for edge case 1 and 2?"
Engineer: "Ah yes, I guess it would be three days then"
Me: "Testing?"
Engineer: "Maybe let's say a week?"
On the other hand experienced devs might have their judgement clouded by past events:
"Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue
No, actually, this sounds quite realistic and in many cases even reasonable. Medical insurance does this literally all the time. Insurance companies of many different kinds in general have to do this to prevent fraud and keep costs (and by extension premiums) low.
> There is no fixed path when modernizing a complex legacy system. There is no rulebook to follow.
Of course not. But as an engineer tasked with this kind of project your estimate should reflect some kind of plan for accomplishing the project, where the plan has more concrete and actionable steps that make estimation easier. And if you are good at your job, your estimate should account for known-unknowns (eg this part is contingent on something partially out of our control and may be delayed by X months) and give enough slack to handle inevitable unknown-unknowns without excessive padding. And uncertainty regarding any particular risks or variance in how long somethign takes should be explicitly noted and communicated.
My $0.02:
The unfixable estimate vs deadline problem ultimately boils down to money. A particular project might be worth it if it ties up 10 people for 3 months, but not worth it if it ties up 10 people for 12 months. And relatedly, businesses oftentimes find themselves needing something finished by a certain time to close a sale/keep a customer happy/catch up to a competitor, and the stakeholders on the other end (customers, investors, partners) need some kind of date for their own planning.
Good estimation is really about identifying the probability distribution of the completion date, rather than a single "expected" completion date, and identifying/communicating the related risks. For a big project this itself probably will take a few days to months to complete and communicate. If you do this properly, there should never be any ambiguity as to what is an estimate and what is a deadline. If you don't do this, you are basically assuming that your manager (and their managers and so on) can read your mind and have the exact same understanding as you do regarding how firm the estimate is + what the risks and possibly "actual completion times" are. You're also denying them the opportunity to help you derisk or accelerate the project by eg adding more people to work on it, reach out to some external stakeholders, or communicating the end date to eg investors/customers in a way that reflects risks. You also need to update the people that care about the completion semi regularly to tell them about any new risks or known unknowns for the same reasons.
If you are wildly off with your estimate even after spending the time to breakdown the project with a more actionable plan, identify risks, and come up with ranges/a distribution of outcomes - let's say you blow past your p99 time to completion - you are probably just bad at your job (or trying to operate above your skill level) and it would probably be very reasonable for your manager to hold you to a deadline with the threat of firing you/canceling the project. Yes, the sunk cost fallacy dictates that even projects that run over should probably be completed in many cases (though since overall budget/personnel are usually constrained I think the opportunity cost of doing other things becomes pretty important). But if people can't trust you to estimate properly they probably can't trust you to lead a project or to have estimated the remaining time to finish the project.
That's cool that they went to Sokcho!! Not many people go to Sokcho but imo it's the best city in Korea, the vibes there are on point, nobody really speaks English and it's pretty dead for the most part, but I really love Sokcho for the vibes, it's maybe the place i've felt the most at peace in my life. If you ever get the chance, I recommend Sokcho. :)
I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…
What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day. Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket ou…
A lot of ink has been spilled on this topic. The solution is simple: get better at estimating. Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable. It's a skill issue.
> It's a skill issue. Maybe. Sort of. Skill hints at the problem, but it's more of an experience issue. More experienced developers can give pretty reliable estimates for work they've already done. The catch is, how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it. So where does that…
It's still a "skill issue" but it's more about knowing how long it will take you or your team. If you don't have the relevant experience with the tech or with the team, you can't really gauge how long something will take.
Before I estimate larger projects I always ask who will be on my team. The estimate is very different depending on the answer.
Earlier quoted context omitted.
Multiply by π — it's more accurate.
Accurate and precise is different things :)
1. If we’re talking about bamboozling people who are either ignorant or willfully obtuse, excess precision is a stupid but useful tool for getting a realistic multiple of 3x-4x past them.
2. If the target audience understands excess precision, the excess precision is a nice little in-joke to flatter them and acknowledge their cleverness.
3. The absurdity of the precision illustrates tha very imprecision of the estimate.