undefined | Better HN

0 pointsethbr11y ago0 comments

Related: I don't know why software estimation doesn't spend more time on risk and less time on estimation.

How much risk (to delivery) is left out there? What can we do to reduce that risk?

It's a known thing, but seems rarely used in software shops. https://en.m.wikipedia.org/wiki/Spiral_model

Who cares if 97% of the code is complete, but the remaining 3% is a critical feature, with unclear requirements, that's never been prototyped, and has no test data?

0 comments

lemonwaterlime1y ago

The challenge is the mindset in most software shops of "We're not building a space ship". Because of the ability to rapidly iterate, there's a sense of invincibility. As we've seen, however, some aspects of the product should in fact be treated like building a space ship. For instance, with something like properly managing data (so you don't get breached), a detailed risk assessment and robust strategy should be more highly prioritized. For displaying a UI to end users, perhaps not so much, but even then there are accessibility concerns that a good product would address.

ethbr1OP1y ago

Safety/security risk is important too, but I was suggesting development keep an eye on delivery risk.

I.e. the risk that a project won't be delivered with the expected features and by the expected end date

Fundamentally, time estimates are useless without a coupled risk/certainty metric.

If you ask me how long something is going to take, and I believe it'll take somewhere between 3 months (worst case) and 2 weeks (best case), what number do I reply to you with? And how do you interpret that number?

And how does my reporting change as we get closer to delivery?

Reducing the size of work being estimated band-aids the problem, by shrinking the absolute magnitude of the bounds, but doesn't fundamentally solve it.

Common heuristics like "double how long you think it's going to take" are other ways this appears.

lemonwaterlime1y ago

I think we’re in agreement. In my mind, you can even get delivery risk from a safety/security standpoint. As in, the product should be developed on time while accounting for the security/safety stuff. And you get there by placing risk front and center for the entire system from the beginning.

j / k navigate · click thread line to collapse

0 pointsethbr11y ago0 comments

Related: I don't know why software estimation doesn't spend more time on risk and less time on estimation.

How much risk (to delivery) is left out there? What can we do to reduce that risk?

It's a known thing, but seems rarely used in software shops. https://en.m.wikipedia.org/wiki/Spiral_model

Who cares if 97% of the code is complete, but the remaining 3% is a critical feature, with unclear requirements, that's never been prototyped, and has no test data?

0 comments

lemonwaterlime1y ago

ethbr1OP1y ago

Safety/security risk is important too, but I was suggesting development keep an eye on delivery risk.

I.e. the risk that a project won't be delivered with the expected features and by the expected end date

Fundamentally, time estimates are useless without a coupled risk/certainty metric.

And how does my reporting change as we get closer to delivery?

Reducing the size of work being estimated band-aids the problem, by shrinking the absolute magnitude of the bounds, but doesn't fundamentally solve it.

Common heuristics like "double how long you think it's going to take" are other ways this appears.

lemonwaterlime1y ago

j / k navigate · click thread line to collapse