← Back to context

Comment by grvdrm

15 hours ago

I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”

16 comments

grvdrm

Reply
stouset  14 hours ago

“The alternative is that nothing will ever get released because devs will take forever making it perfect” is a really lame take.

We have literally countless examples of software that devs have released entirely of their own volition when they felt it was ready.

If anything, in my experience, software that’s written a little slower and to a higher standard of quality is faster-releasing in the long (and medium) run. You’d be shocked at how productive your developers are when they aren’t task-switching every thirty minutes to put out fires, or when feature work isn’t constantly burdened by having to upend unrelated parts of the code due to hopelessly interwoven design.

noisy_boy  10 hours ago

I think PMs fail to understand categories of change in terms of complexity because they focus on the user facing surface and deal in timelines. A change that brings in a big feature can be straightforward because it perfectly fits the existing landscape. A seemingly trivial change can have lot of complexities that are hard to predict in terms of timelines.

There is also the angle of asking for estimate without allocating time for estimation itself.

For lack of a better word, I think it should drive from "complexity". Hardness of estimate should be inversely proportional to the complexity. Adding field to a UI when it is also exposed via the API is generally low complexity so my estimate would likely hold. We can provide estimate for a major change but the estimate would be soft and subject to stretch and it is the role of the PM to communicate it accordingly to the stakeholders.

dylan604  15 hours ago

Some coding doesn't fit your schedule. If you've scheduled 2 weeks, but it takes 3, then it takes 3. Scheduling it to take 2 does nothing to actually make the coding faster.

  • grvdrm  15 hours 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  15 hours 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.

      5 replies →