[dolni]

> Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.

The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.

The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.

In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.

I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.

[rglover]

Author here. This is the correct interpretation of what I was getting at.