Comment by andrekandre

2 days ago

  > Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. 

ironically, giving more time upfront can make things faster because people now have time to make a proper implementation, so you have less rework/qa cycles...

I don't think it is ironic, but makes perfect sense. It's about the marathon strategy.

I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing with time is that if you finish ahead of schedule you can just go onto the next thing. It's always better to finish ahead of schedule than behind. But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.

  •   > It is hard to predict disaster, but you can prepare for it.
    

    yes, you need slack to deal with inevitable surprises and delays that will occur so that you can actually make it 'in time'

      > But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.
    

    this is counterintuitive for a lot of people and especially for managers under pressure from above

    running without slack means every bump in the road adds a delay which makes the manager's troubles even worse when they have to report the inevitable delay (which leads to a negative spiral of rush-and-delay)