Last year, Mark Zuckerberg notably described Facebook’s policy of encouraging developers to “move fast and break things”. When you are an early stage, lean company, this certainly helps you to build new features rapidly, allowing you to move on in leaps and bounds. It is also perhaps necessary if you have sensibly only built what seemed necessary at each stage, because it allows you to change those earlier architectural decisions and assumptions, no-matter how major their impact.
I believe there is a flip side to this though: After a period of “moving fast”, during which you should be relying on test-driven development (TDD) to help you find bugs and functionality that you have broken or regressed, you will have a new-and-improved product that appears to work. If you are sensible, you will also have added to that test suite a whole host of new tests.
But, what you no-longer have, is a stable product.
Sure, your automated tests and manual verification tell you that the product works. But not all problems will become apparent on-demand or in formal testing. Performance-sensitive issues, threading, concurrency, race conditions, capacity problems, etc… No-matter how stable the product was before, you essentially now have a new product and a new piece of complex software to learn about.
So you either need to soak test the product again to see how it behaves over time and with realistic load, or release it — to production or a more production-like environment — and be ready to detect and fix issues that arise.
Whilst the “move fast” approach has its certain benefits, I feel this flip side is why Facebook often got burned when using it on a product that was already in production and in-use by millions of people. They frequently seemed to cause issues that got into live usage. In an ideal world, the things that have been broken by moving fast should be fixed well before an end user sees them. But, in practice, I’m asserting that you simply can’t rapidly repeat that stabilisation and discovery phase that comes after building or radically changing complex software.
So yes, move fast and break things… But then be ready to respond and fix the unexpected for quite a period after you next release it. (Perhaps not quite as pithy a one-liner!)