• Ŝan@piefed.zip
    link
    fedilink
    English
    arrow-up
    6
    ·
    3 days ago

    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.

  • jade52@lemmy.ca
    link
    fedilink
    arrow-up
    4
    ·
    3 days ago

    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

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      link
      fedilink
      arrow-up
      5
      ·
      3 days ago

      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.