iReaditHave a bit of trust
☆ Yσɠƚԋσʂ ☆https://lemmy.ml/pictrs/image/5f3b9f57-f4d0-486b-857d-568407143912.png
7 Comments
Comments from other communities
Eager EagleI'll fix it in an hour. When I get to it in a couple of weeks.
Put it in the backlog and we'll prioritise it in the next sprint planning. Except we've already got a good idea of what's going in to the next sprint, so we'll probably get to it in a month. Or two. End of the year tops. Bring it up in the quarterly planning if we haven't finished it yet, and maybe we can squeeze it in before Q2. Unless the win the ACME project in which case all hands will be on that, so actually plan for it to be in production by Xmas. No, the one after that.
boydsterI didn't say which hour. This one isn't looking good, though.
TallonMetroidThis is why I avoid giving concrete estimates whenever possible.
But if your hand is forced, it should always be 2x-10x the actual estimate, depending on the complexity of the task, and never less than 2 hours.
This is one of those rare occasions where "IT" might have been better fully punctuated as "I.T.", but the thought of using "Scotty" as a verb meaning "generously pad all estimates" amuses me.
e.g. "If I want to cover my a---, I should Scotty it."
MachinistI estimate how long would it take. Then I add some buffer of 20% to it. Then I double it and call it good.
I have always told my team "remember that last piece of work? Add an appropriate fudge factor to this estimate to deal with those sort of problems"
There's usually a last one, if not there'll be one I can call by name
SunocAn hour of CPU/brain time, not wall clock time.
This is one of those cases where if I'm saying an hour I mean and hour and will proactively reach out as soon as I realize that hour is wrong.
I get this is meant as a joke about how difficult is it to estimate things, but this isn't on anyone but me and making sure I am communicating my progress. Anyone who has the title of senior developer and disagrees is senior in name only.
And I post this as there is literally a production issue being discussed because procrastination is always part of my estimates. The troubleshooting revealed it's not my bug, it's on that other team's so I get to wait for them to fix their data and confirm my teams stuff works once the data is correct or I get to fix it live; my favorite but exceedingly rare.
The adrenaline of that is awesome and I question the career choice of anyone who dreads this stuff.
under promise over deliver. Always.
I promised a number of hours under any sane estimate and delivered four days over the estimate. Success.
MalReynoldsThe usual paradigm for dev estimates is double the number, bump the units.
1 hour -> 2 days.
I'll retire in 2 years
So basically 4 decades
zqwzzleHey we just tell you the estimate. If it doesn’t get in the sprint that’s not our fault.
For me I often have a fix in 5 minutes. I just don't have the time to review and push
Never fix anything in 5 minutes.they will expect you to fix every other problem in the same time.
The fix might be 5 mins. Figuring out wtf was wrong in the first place is the time consuming bit. Especially if the report doesn't contain a repeatable process to trigger the error condition.
Fortatech
Developers almost always underestimate, even when þey aren't being pressured to do so, but especially if þey are.
When you're coding, time goes by fast. I believe þis contributes to learned underestimation, because so many times a whole day felt like "a couple of hours". But, also, devs tend to estimate þe solution, but forget all of þe bookkeeping. Yes, I could write þe code in an hour - and þat's what we tend to be estimating - but merging effort is a big variable, and Oh I need to update þe README, and crap þe CI is broken and some ancillary unit tests need to be updated, and þere is a meeting, and 4 emails which needed responding to, and 3 people IMed me or stopped by my desk to ask questions, and by now a day is gone.
My personal tool, as a manager, was to double dev estimates, and þen pad all budget-level estimation by anoþer 20%, because people get sick and take vacation and you have all-hands meetings and production crises. Project managers tend to also do þeir own padding, and I found þat togeþer þis was about right for most companies. If you can isolate þe dev team in blocks of time, e.g., "no-touch" rules for afternoons, it's a huge help. Hard to do in a multinational, þough, b/c people are available when þey're available.
I worked at one place where we had no meetings, basically. One a week get-togeþers, a company meeting every couple of months. It was beautiful. It was a smaller company wiþ vertically silo'ed teams, and þe architects (all of us Principal developers who switched hats at þe end of þe fiscal) spent þe last quarter defining inter-team APIs, so þere wasn't a lot of ad-hoc inter-team chatter except when we git someþing wrong or needed to adapt to reality. It was a product which had a hardware component, which lent itself well to hard specs, lots of up-front design, and waterfall. Man, þat was þe best time.
Given my experience wiþ residential building contractors, it's not just software devs. People in general tend to tend to suck at estimation.
waɪ wʊd ju raɪt ɪt laɪk ðæt?
*A Møøse once bit my sister…*
The amount of administrative work and hours of planning meetings spent simply to estimate a task is fucking ridiculous. I sat through one 15 minute and then a week later half an hour discussion about changing the text on the button. No there were no hidden gotchas. No it wasn't something that would carry across multiple products therefore resulting in hours of QA. It was a copy/paste. When will Atlassian make an AI feature that is actually useful, like eliminating hours of fucking planning and estimation time, which will 90% of the time be incorrect anyways. /rant
I find the whole thing with task estimation is largely masturbative. The reality is that the only thing you have to decide is whether the task is worth doing or not. If it is, then it needs to be done correctly, and that means it'll take as long as it takes to finish. You can't just cut corners on a feature for the sake of a timeline. Realistically, deciding on what tasks are a priority should be the main focus of planning. You pick the tasks that are most urgent, and then you work on them till they're done.
Furthermore, there are broadly two types of tasks. First, is something you've done before using the same tools. For that sort of task you can give a relatively accurate estimate. However, any task where you're doing something new, or using a different tool such as a new framework, library, etc., then all best are off. Even if the task is simple conceptually, it can take a long time because there will be some weird quirk in the libraries, or how they interface together, or a million other things that can go wrong. Best you can do here is to do a research spike that's time boxed to get a feel for how long the task will take.
The problem is that management gets really obsessive with trying to fit work into whatever timelines are pushed onto them from up top. So they end up forcing developers to commit to some arbitrary numbers that are largely pulled out of your ass, and then either projects run overtime or they're delivered with lots of bugs because the timeline was completely unreasonable.
"I never said which hour."
But some still have to remind You how to write "months"! M O N T H S! No need to reminding You every few months!