Why are time estimates often REALLY wrong? - MPJ's Musings - FunFunFunction #45
Вставка
- Опубліковано 4 жов 2024
- 💖 Support the show by becoming a Patreon
/ funfunfunction
Original article by Michael Wolfe
goo.gl/aZ2PK5
Playlist of more episodes like this one (MPJ's Musings)
goo.gl/RlTSrU
I'm also active on:
• Twitter / mpjme
• Medium / mpjme
• Quora www.quora.com/...
.. when they finally get to the destination and call 30 minutes beforehand to their friends, the friend tells that they have moved already a year ago to a different city and thought that you knew about that.
I always tend to come back to this video when suffering burnout. Helps to know I am not alone.
My first development job had me learn to generally triple any estimate made. In part to account for unforeseen trouble - in part to account for the fact that my boss would generally then cut any estimate I made in half and give me a deadline according to that. What he expected to achieve by that move, I never did catch.
Snap Gert! My method has also always been to triple the total of my broken down task estimates too (15 years+ as a developer). I feel your pain about your deadlines being half of what you needed. Micro managing estimates and quarreling over a gantt chart is never the answer for developing quality software.
I think the important thing with estimation is to be honest, open and realistic from the outset and to give a worst case time estimate up front to set expectations, but always to give the caveat that in order to ensure quality, things will be done when they are done, not just because of a deadline.
Sometimes deadlines are needed, but often they are not, or only part of the scope has time considerations. The special sauce (like most things in IT) is information - being open and honest about how things are going, what is important and what isn't so important and constantly evaluating what is left to do and how long it is likely to take.
In my humble opinion, IT needs less project managers and more facilitators who can just listen and collaborate with developers, clients and service providers to understand how to keep projects ticking along smoothly.
Thanks MPJ, I've really been enjoying your videos.
Tim Harris I'm in a better place now - have been for years, and different places at that. So I was mainly sharing unpleasant memories. ;-)
Generally, my experience has been that the best time estimates are loose, and made based on as small task fragments as achievable. Most of us can estimate whether something will take half a day or a whole day, but estimates get less meaningful when we have to guess if it's going to be one week or two.
Task estimation tactics based on that truth, plus the fact that no group or individual works at perfect concentration and velocity for any appreciable amount of time, instead needing time for e.g. meetings, SNAFUs, sudden bug fixes, etc., are the better and more truthful ones.
What the hell? Why would he cut the estimate in half when estimates are usually too low? I am completely lost here.
godwavenexus I have no idea. And yet, he's not the worst manager I've had!
What an ignorant leader. Disgusting.
I really enjoyed this video. Even if it was a rehash of a Quora answer, your narration is awesome, and it's a welcome change of pace from your usual videos.
While we're on the subject, I have read a book on SCRUM and I can't seem to muster up the courage to tell a client, "I'll tell you when we can finish the project, in about 3 months."
Again, great video!
The sooner you do it the easier it will be, the longer you wait, the harder.
When I was a proponent of SCRUM, the one thing I already knew was that estimates were just guesses. If the team doesn't change and the work is predictable then the team should get more accurate at understanding what they can get done. That aside, the main thing I've found is that allowing your Product Owner to have a vague understanding of the order of work and when they might expect to be seeing progress on an item is important when you've got eager stakeholders. To do this, what I'd tell my team to under-commit. If they overachieve in a sprint that's great, but if they underachieve it might get stakeholders concerned.
Nowadays I'm not on the Product Owner, so I'm on the 'no estimates' camp, but in an organisation where 'agile' is an IT-only thing I can understand that moving away from estimates is difficult.
And then the client says to you "Can't you do the whole trip in five days? Shouldn't take you long. All you have to do is walk, should be easy, where's the problem?"
Pretty accurate and underrated comment :)
Having already read the article before watching this I still immensely enjoyed the dramatic reading. Spot on!
Story of my life! Let's not forget those trips where you stumble through a wormhole that drops you off a mile from Las Angeles on day 1.
While you're speaking of real-world projects, I feel it describes my trajectory in programming. I've enjoyed programming since I began in February. As obstacles occur, it’s difficult to get outside of oneself and continue. The best thing to do is keep going, even if you’re sixty-days out. You really have to be honest w/ yourself in programming, simply no other way. Great video, MPJ. I hope to work alongside people like you when I get there.
started my first programming job, had to make a couple of estimates... collectivly took 2 times longer then expected... i was surprised when my boss was like "dont worry, I tripled your estimate, but im sure you learnt from you suffering"....lesson learnt haha
This article is a classic! Great pick
So, did they make it? Did someone die? It can't end that short! lol
Great story. Good to know I'm not the only one who is incapable of giving good time estimates. Seems like the lesson here is just don't do it, no matter what you think you know, you can't predict the future. I like the idea you mentioned in the comments about timeboxing and using smaller icrements. Thanks
Love this ep. So coo platelet describes most programming estimates. Thanks MPJ for brining this to us!
This was awesome! That "buffer time" you want to add on to the estimate really feels temping to just nip away bit away. Great read. I laughed.
Great video .. as always :)
I think the machinery in the "holes" in the forrest at 5 mins are for lifting and lowering targets on a shooting range. Can anyone else confirm this ?
Agreed. Those are target frames.
I started a handyman service to get out of homelessness, I learned VERY quickly to triple time estimates and still stick to that. Now I'm taking programming at a code boot camp in Seattle and I apply the same rule, only I quadruple my time estimates, lol!
where you walking in some sort of old military training grounds, the things you found, could it be "pop up" targets?
(great talk by the way :) )
This was great and really hits home! :D
I read somewhere that if you, say, have a top developer who can hit any estimate he give 95% of the time, and you ask them to estimate the completion of 10 sequential tasks, that when they then execute those tasks, there is only a 60% chance of them completing them as per the estimate.
I don't get estimates right 95% of the time - I don't think anyone does.
Then mix in a software project with dozens of people, and hundreds of tasks, and technical risk, vendors, audit, compliance, reporting, bugs in tools, downtime in environments, change in process/personnel/tooling/managers.
Estimates built on estimates of more estimate are a losing proposition.
It's both a great and horrible comparison. It's great because it illustrates how easily overlooked things are.. It's horrible because most multi-day hikers don't make such large miscalculations - and if they do, it's because of total inexperience, not dealing with the 'unforseen'. Since thru-hikers typically travel in the backcountry, rarely are you misjudging your timing so poorly - you simply can't afford it.
This was one of your best episodes. :)
Well, mpj, this was my second viewing of this episode and I think I laughed louder and longer than the first time. Classic!
This made me very happy.
It's like a modern day "Mythical Man-Month". The forest reminds me of this Swedish town called Herrang, I often spend my summers in.
+Rony Sheer you're a fellow Lindy hopper!
Great video once again. Can i ask how you handle estimations of your own? At my work we used to do poker planning but have abandoned it for an equally thumbsucking method but takes less time.
+SayuStrife I am horrible at time estimations and I doubt that I've made a single one successfully in my career. I frankly find the term estimation for software projects to be fundamentally problematic, unless you're setting up a Wordpress installation or something. We're not carpenters building houses from blueprints. If a software developer has a blueprint its likely automated and will be near-instantaneous to make. If you're developing, you are per definition doing something that you have not done before (if it was, it would be close to instant to do) so you're per definition incompetent at making the estimation.
I like to mitigate the fact that I too suck at estimations by using story points (a.k.a. estimation points) and recalculating velocity iteratively. It's like the part of the story where the author realizes they've walked x amount of miles, and hence can recalculate the initial time estimate of 10 days to 70: As you make progress, your estimate becomes more accurate. It's important to make sure stakeholders understand that estimations are not accurate and that they will get more accurate as you make progress. Using a unit of measure that's more vague (e.g. weeks or months instead of days or hours) also helps drive the point that your estimation is not accurate from the beginning. Using precise units of measure leads to a misleading sense of accuracy and then a 720 hour delay becomes much harder to swallow than a one month delay, even though they are the same thing.
It's quite common to use holes in the ground like the one you've found to check out vehicles. I reckon that you've found a rest of a workshop that was dismantled
HI MPJ! This is unrelated but I wasn't sure if you'd prefer having this question here or on twitter. I really like what you're doing here, and the way you talk and think about programming in general. While I enjoy some of your more "teaching" videos, I'm really more of a beginner programmer and they're not exactly targeted at my level, and i really wanted to ask you where would you point someone who's a little too beginner for your videos to get up to speed with javascript and programming? Thank you very much.
+MrDisco have you checked out devtips and learncode academy?
Yes I have! And I'm also reading Eloquent Javascript and doing some freecodecamp. I guess I was looking for your insight since you've been the most inspiring (kinda like a model) and I'm still unsure which one of theses things going to make me feel like I've covered all the foundations of JS and can call myself a Js developer and start an internship.
4:46 That's a weird hole in the middle of the forest.
Great example for time estimation, I recognize myself a lot in it. Thanx also for introducing Michael Wolfe. He seems to have more wisdome. But how can you solve this problem, if you want something to be done and if your ProductOwner would kick it anyway if you'd double or even tripple your personal estimate.
Dont do it.
Right answer. Also, cutting scope could be acceptable.
+Rick Hernandez and how Can you do Tech shifts then like introducing webpack in you former js only Project? such a thing Can mean you have to modify each source file to enter the missing require statements. or be it what ever improvement you want to place in your project.
+Christian Hörauf An organization that builds software effectively needs to constantly monitor progress and adapt accordingly. It treats software as an ongoing process rather than a building that needs to be completed. Build in tiny deliverables so that you can produce value fast and get feedback from the customer.
All of my current and previous project managers (and their bosses) should see this :)
ardalis.com/wp-content/uploads/2015/11/estimates-deadlines.jpg
When I give someone else an estimate I typically double what I have estimated myself. This allows me to look good if I do actually make my target, and not look so bad when I end up taking twice as long as I thought (which is what typically happens).
The above strategy fails when working on my own and giving myself estimates as I don't double it.
Too close to home. This is what my nightmares are like.
If you build software for a company, there are always time estimates and they always get pushed back. There are also size estimates and all of that takes a lot of energy to assess, but one has to do it. If there is no time estimate a developer is committed to - there is no self-accountability. As a manager, I understand that unexpected happen, but I never bash anybody for missed deadlines. Estimates work similarly to college semester tests: no matter how soon a deadline is and how unprepared a student is - a student would be ready by the deadline :)
+Alex Kovshovik I've worked in multiple projects where we did not use time estimates. I vehemently disagree with your statement that self-accountability cannot be achieved without time estimates.
+Alex Kovshovik don't want to deny the usefulness of deadlines of timeboxing, I use them all the time, including this channel, but implying that time estimates are a fact of company life is misleading.
I guess, you're right - one CAN achieve self-accountability without estimates, but if a manager asks a developer to provide the "approximate" estimate and then developer honestly tries to deliver on time - this doesn't hurt. Estimates are never facts - that's for sure!
I like your accent very much BTW :)
Looks so good! ⭐🎥
Great Material! IMHO... Coding, just like walking it is much more efficient when it is done by ONE person. Group walks as fast as the slowest person, and adding the second person to the SW project slows it incredibly! One person, with enough resources, should just walk the whole thing and then map the route. And if it's impossible - that's fine - whole team's effort is not wasted. And if he can make it - then we can add 1 or 2 people to the team and do the second iteration under his lead!
+Anton Loss the "surgeon" thesis is often cited but it is just not a maintainable attitude. Only software of a trivial size can be built and maintained by a single person. And even if that wasn't the case, you are making your team dangerously dependent on a single person.
you should revisit the "weird crap in the forest". coordonates maybe?
I would love to see a follow-up on your thoughts about what can be done to improve our estimates :)
+John Meegan I don't think estimates can be improved much, they are guesswork and is influenced by a ridiculous amount of factors and is as useful as tarot readings (i.e. that they are somewhat useful in the sense that they make you think about and visualize the future, but are destructive if you rely upon them for actual planning). I think that estimates should largely be replaced with timeboxing, small deliverables of value to the customer in small iterations, and recurring progress updates. I.e. Gauge actual progress and value delivered over time, not trying to predict the future. Future prediction and arbitrary commitments in an organization that works with software innovation needs to be replaced with ongoing communication and flexibility.
I also think that what people mean when they say "estimation" they actually don't mean that, they mean "commitment". They want you to go out of your way to guarantee for them that something will happen at a certain time. This is understandable, it is very convenient to have certainty, but unfortunately it cannot realistically be provided in a customer-software developer relationship, for many reasons. Partially because software development itself is impossible to predict (because we are per definition building something that has never been done before, if we're actually developing something and not just configuring a CMS etc) but also because the customer themselves have influence over the project and can (and almost often will) request alteration that topples any time estimation on its head.
Thanks for the detailed reply. It makes sense but is hard to sell :)
So what is the solution? Uncle bob recommends you multiply all estimates by five.
one of the most stressful things is when a client says "oh I just want to add this little thing - it shouldn't affect the schedule" and they dont realize that they are actually asking for something really big ;)
Loved the show as always, btw! :)
Time estimation is at best an art, at worst a stress inducing waste of time. :) I find my estimates are often not big enough, so next time I make them even larger, then they're grossly over estimated or the project / task doesn't get green lit. What a mess. :)
This podcast episode on the same topic is worth a listen: www.fullstackradio.com/31
"In this episode Adam talks to Woody Zuill about software project estimation. They talk about the #NoEstimates hash tag, and what it means and where it came from. They also talk about ways to manage software projects without worrying about estimation, and alternative ways to make the decisions that estimates are usually used for."
I like this.
did you memorize the whole text? Incredible.
+seemsas God no. Heavy editing going on here. ;)
damn I think I have to call my friends ;) ty for the video
Oh my goodness, I laughed so long and hard! So very true, estimates tend to forget about life being full of life. I have lived the project cycle described in this post too many times :D Planning fallacy is such a common problem it has made it to the bias list :P rationalwiki.org/wiki/List_of_cognitive_biases
MPJ... mind if I send this to ALL of my future clients? :D
did it on friday, shit's legit!)
mhm the clients will not understand ... they will say I am the CLIENT I pay You do... or at least most of them say something like this from my exp ... eh ...
Hey, this has nothing to do with this video but I'm proposing a video about Object.getOwnPropertyDescriptor(), Object.defineProperty() , if you have used and why? Thank you :)
+Rolando Barbella I think they are largely meaningless addition to the language, to be honest. Why not simply use functions?
Yeah well, I'm reading the You don't know Js (this & prototypes) book by Kyle Simpson, where there is a chapter about that, I was curious to know if you will use them in real scenarios, I guess yo clear my doubt :) Thank's for the answer!
This video was deep. Thank you. You managed to explain everything without giving an explanation. So zen. gg
Hilarious! Time is an abstract concept to the mind. We can manipulate it in ways computers cannot.
Hope you found rare Pokemon !
Could you do a video or just answer what programmers you follow and find inspiration from?
+NeoChromer Jonathan Blow, John Carmack, Rich Hickey, the dude that wrote Mythical Man Month.
funfunfunction Thank you very much! I actually follow some MS developers like Scott Hanselman, but since I switched to JS and Ruby I kinda lost track of their works.. :/
Fred Brooks wrote Mythical man month (Not that I don't think you know!). I sat next to him in my Advanced Web Programming class as he audited my professor at UNC. The man has an office in a building named after him (Brooks' Hall at UNC-Chapel Hill) and is a legitimate legend and all around nice guy. Brooks' Law from MMM: The more people you add to a late project, the later it becomes. This is one of the things I have seen over and over again. To tie to the video/article, if you added 5 walkers to the party they would not have sped the progress, but gotten their own blisters, their own fevers and only made the trip take even longer. Love the videos!
he didn't talk about javascript right ?
so accurate.
Hey, just take the buss and pretend you walked :)
but yes, time estimates are very difficult. I usually multiply my estimates by pi, that gets things a bit closer to reality.
I believe those rising shooting targets.
Oh, that would make sense! Lots of old military stuff around the area.
Yeah, definitely looks like it.
so whats the answer?
I think it's just "you cannot predict the future" and that's it.
It's all part of the human experience. Things happen. Learn.
Weird things in the woods are usually remnants of the war.
Which war? The US has been in several.
I'm pretty sure the US has never been at war in Sweden. I could be wrong though.
Oh lol. I got caught up in the story and was thinking he was in California or something. lolz. I feel hilariously foolish right now.
Sounds like that german dude from Django unchained.
Please don't use miles..
I believe he was reading verbatim, so miles were not Mattias' unit of choice.
Should consolidate lint configs
first :)