Yep - there are benefits to a slogan being counter-intuitive because the whole point is to challenge the intuitive way of approaching a problem and making you see it anew.

In the reverse case, facebook's "move fast and break things" works because it suggests you move fast enough to dare breaking things to try an overcome the caution that holds people back from doing great things.

In this case the equivalent slogan might be "Do it right and ship it late" i.e. its so important to get it right its worth risking missing a shipping date. Practical principles, like the agile manifesto, describe a preferred trade-off rather than just naming a good attribute like swiftness, because who doesn't want the good attribute? It would be irrational.

I think this also highlights why moving faster is nearly always better even if uncomfortable for some: its a more effective way of handling uncertainty and learning faster that in most commercial environments is more important than quality. Quality in the wrong places is waste.

This is also why I don't think moving faster is almost always better. There's a certain point at which moving faster slows you down.

A better way of saying it might be "optimize your progress over the next 10 years, not over the next week."

I think there is a false choice usually presented between agile, move fast and break things, vs old waterfall approach. I don't think waterfall is the right alternative. The waterfall approach is really difficult to get right because to some extent it insulates design from coding. The integration of these two is something that agile gets right.

But what agile gets wrong is in de-emphasizing design too much. Design is important, and it is important regarding long-term progress. And if you don't design, you will pay for it a hundred times over. But the best design is where technology is designed bottom-up and UX is designed top-down. Done right, this integrates design into coding but it also emphasizes design and code contracts.

I am not sure that ship it late necessarily becomes a part of slow coding. The point is to code deliberately and with quality. Once you have a production codebase, if you do things right, there's no reason you can't ship on a fixed schedule. You might ship less initially than you expected, but in the long run, you will ship more than you expect, because the delay of design pays back later.