Is it still suitable to code loosely when people use your trivial SaaS as if it were a vital component of their life? And if you encourage people to do so, isn't it irresponsible to keep applying such a methodology?
I think you're missing my point. It's not coding loosely, it's optimizing moving quickly. And by moving quickly you can actually have a safer and more secure site than by, say, only releasing code every 3 months or something.
This confuses the act of shipping code frequently with what the code actually does. Both of those are important but don't really have any bearing on each other.
fwiw, I disagree strongly that moving fast and breaking things "might be the singularly most important software engineering mantra of our age." Frankly, this terrifies me. You already qualify it by carving out banks, space shuttles (and presumably medical devices, transportation, etc). I suspect we could discuss a list of things where it doesn't quite apply and in the end I would have to add "...for products that aren't critical to your users." to the end of your sentence.
"Move fast and break things" is about moving fast, and only mentions "break things" to indicate that its OK to break things. I agree that what the code does is orthogonal.
I would carve out space shuttles, etc, as different, but they already are carved out: they use special subsets of C with no memory allocation, run extensive static analysis and proof software, because those things literally cannot go wrong.
Anything that doesn't use that sort of thing has already committed to the idea that it won't be foolproof. If you code in a scripting language, you are already writing software which you implicitly acknowledge can go wrong. Software has bugs!
I guess my issue is specifically with 'break things' as it overgeneralises the idea of experimentation (which is something I do agree with). The impression that 'move fast, break things' leaves me with is that it's ok to break anything and that it's also (implicitly) not a big deal if they stay broken or somehow hurt a user (e.g by exposing, even temporarily, what was once private).
Even though it's a wonderfully pithy 4 words, people can interpret them in many different ways, most of which I'd argue are not good for the end-user.
"... you are already writing software which you implicitly acknowledge can go wrong. Software has bugs!"
Agreed, but shouldn't the intent be to create things in a way that tries to reduce the likelihood of damage while still allowing plenty of room for experimentation? i.e take some care that what you're about to do/push isn't going to do harm? If I follow the 'break things' mantra, I don't need to care. That's what bothers me. It's so easy to hide behind when something goes wrong.
From what I've learnt of Facebook's attitude, it's more that you won't be fired if you take the site down (at least, the first time). I don't believe that they don't care when you break things, and that wasn't what I was advocating.
