> The current practice of "move fast and break things" very well could be a better approach. It's all about context. What's the cost of "breaking things"? Do

> The current practice of "move fast and break things" very well could be a better approach. It's all about context. What's the cost of "breaking things"? Does your not-yet-monetized social network startup go down for a couple of hours? Or does someone die? Also, I have witnessed first-hand the slowdown in productivity that a "move fast and break things" approach has when what you are breaking is your team's ability to work quickly and confidently with the code base.