4 ms·

3 sounds fine. Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it). Add upfront. Then

by grvdrm 6mo ago

3 sounds fine. Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it). Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”

DrewADesign 6mo ago
The fundamental problem remains: it’s difficult to predict how long it will take to solve a series of puzzles. I worked in a dev group where we’d take the happy path estimate and double it… it didn’t help much. So often I’d think something would take me a week, so two walls was allotted, but I made a discovery in my first like hour/day whatever that reduced the dev time to like a couple days. Then, there were tasks that I thought I’d solve in a few days that took me weeks because I couldn’t foresee some series of problems to overcome. Taking a guess and adding time to it just shifts the endpoint of the guess. That didn’t help us much.
- grvdrm 6mo ago
  That's the point I am making, and the point of asking "what is the alternative" Developers aren't alone in adhering to schedules. Many folks in many roles do it. All deal with missed deadlines, success, expectation management, etc. No one operates in magical no-timeline land unless they do not at all answer to anyone or any user. Not the predominant model, right? So rather than just say "you can blame the PMs" I'd love to hear a realistic-to-business flow idea. I am not saying I have the answers or a "take". I've both asked for and been asked for estimates and many times told people "I can't estimate that because I don't know what will happen along the way." So, it's not just PMs. It's the whole system. Is there a real solution or are we pretending there might be? Honest inquiry.
  - dylan604 6mo ago
    Software release dates are so arbitrary though. We no longer make physical media that needs time to make and ship. Why does software need to be released on February 15th instead of March 7th?
    - wat10000 6mo ago
      You could ask the same question about the contents of the release. Why does software need to be released with features X, Y, and Z on March 7th when it could be released with features X and Y on February 15th? It's inevitable that work will slip. That doesn't necessarily mean the release will slip. Sometimes you actually need the thing, but often the work is something you want to include in the release but don't absolutely have to. Then you can decide which tradeoff you prefer, delaying the release or reducing its scope.
      - grvdrm 6mo ago
        This is the direction of my thinking, too. Earlier discussion focuses on writing software at a slower pace to inject more accuracy and robust thinking/design/code. Conceptually, yes, I get it! But in numerous practical scenarios, some adherence to a recurring schedule seems like the only way to align software to business outcomes. My thinking is tied more to enterprise products (both external and internal) rather than open-source. I like an active dialog with engineers. (I'm neither SWE nor PM). Let's talk together about estimates. What's possible and not possible. Where do you feel most uncertain, most certain. What dependencies/externalities do you expect to cause problems. Those conversations help me (business/analytics-side) do things like adjust my own deadlines, schedules. Communicate with c-suite to realign on what's possible and not. Adjust time.
        DrewADesign 6mo ago
        The main problem I’ve had is the unpredictability of where the complexity lies. Unless you’ve done exactly what you’re doing, before, with the same tools and requirements, there’s a good chance that some discrete trivial aspect could take up an incredible amount of time, and that won’t indicate whether the main goal will take more or less time. I’ve worked both as a developer and as a designer, and while some aspects of design can be really nebulous and uncertain compared to dev work, it lacks some of the unpredictability — it’s not like I’m going to unexpectedly have to re-make the logo. I feel for anyone that has to wrangle these tasks into a business-consumable time frame.
dylan604 6mo ago
You assume that PMs will just accept whatever estimate you give and not just say 2 weeks from the off and refuse to budge.
- grvdrm 6mo ago
  So, could you say "ok, but I still can't do that"
  - noisy_boy 6mo ago
    In this day and age of code-in-bulk enabled by AI, they will find someone who does in a blink of an eye.

by grvdrm 6mo ago

DrewADesign 6mo ago

The fundamental problem remains: it’s difficult to predict how long it will take to solve a series of puzzles. I worked in a dev group where we’d take the happy path estimate and double it… it didn’t help much. So often I’d think something would take me a week, so two walls was allotted, but I made a discovery in my first like hour/day whatever that reduced the dev time to like a couple days. Then, there were tasks that I thought I’d solve in a few days that took me weeks because I couldn’t foresee some series of problems to overcome. Taking a guess and adding time to it just shifts the endpoint of the guess. That didn’t help us much.

grvdrm 6mo ago
That's the point I am making, and the point of asking "what is the alternative" Developers aren't alone in adhering to schedules. Many folks in many roles do it. All deal with missed deadlines, success, expectation management, etc. No one operates in magical no-timeline land unless they do not at all answer to anyone or any user. Not the predominant model, right? So rather than just say "you can blame the PMs" I'd love to hear a realistic-to-business flow idea. I am not saying I have the answers or a "take". I've both asked for and been asked for estimates and many times told people "I can't estimate that because I don't know what will happen along the way." So, it's not just PMs. It's the whole system. Is there a real solution or are we pretending there might be? Honest inquiry.
- dylan604 6mo ago
  Software release dates are so arbitrary though. We no longer make physical media that needs time to make and ship. Why does software need to be released on February 15th instead of March 7th?
  - wat10000 6mo ago
    You could ask the same question about the contents of the release. Why does software need to be released with features X, Y, and Z on March 7th when it could be released with features X and Y on February 15th? It's inevitable that work will slip. That doesn't necessarily mean the release will slip. Sometimes you actually need the thing, but often the work is something you want to include in the release but don't absolutely have to. Then you can decide which tradeoff you prefer, delaying the release or reducing its scope.
    - grvdrm 6mo ago
      This is the direction of my thinking, too. Earlier discussion focuses on writing software at a slower pace to inject more accuracy and robust thinking/design/code. Conceptually, yes, I get it! But in numerous practical scenarios, some adherence to a recurring schedule seems like the only way to align software to business outcomes. My thinking is tied more to enterprise products (both external and internal) rather than open-source. I like an active dialog with engineers. (I'm neither SWE nor PM). Let's talk together about estimates. What's possible and not possible. Where do you feel most uncertain, most certain. What dependencies/externalities do you expect to cause problems. Those conversations help me (business/analytics-side) do things like adjust my own deadlines, schedules. Communicate with c-suite to realign on what's possible and not. Adjust time.
      - DrewADesign 6mo ago
        The main problem I’ve had is the unpredictability of where the complexity lies. Unless you’ve done exactly what you’re doing, before, with the same tools and requirements, there’s a good chance that some discrete trivial aspect could take up an incredible amount of time, and that won’t indicate whether the main goal will take more or less time. I’ve worked both as a developer and as a designer, and while some aspects of design can be really nebulous and uncertain compared to dev work, it lacks some of the unpredictability — it’s not like I’m going to unexpectedly have to re-make the logo. I feel for anyone that has to wrangle these tasks into a business-consumable time frame.

dylan604 6mo ago

You assume that PMs will just accept whatever estimate you give and not just say 2 weeks from the off and refuse to budge.

grvdrm 6mo ago
So, could you say "ok, but I still can't do that"
- noisy_boy 6mo ago
  In this day and age of code-in-bulk enabled by AI, they will find someone who does in a blink of an eye.