[paisawalla]

This is inane, frankly. There are people who code to a much higher standard than this. People live and die by the code they write, so they can't accept "things break all the time ..." and forget about writing correct code.

See for example: your car, your bank (not the website, the backend), the space shuttle, the Fed, anything important. Some places cannot accept the supposed fact of frequent outages and failure, and engineer for that reality instead.

I don't know how you're concluding that the hackday coding methodology creates more secure code, unless you are simply unaware of the industrial standards to which other fields' programmers are held.

[pbiggar]

Of course I wasn't talking about banks and space shuttles, that would be inane. Some places can't accept outages and failure, and naturally "move fast and break things" is an unacceptable mantra for those places.

However, few companies are rated on the quality of their code. Rather, most companies are rated on how well they serve their customers needs, including the vast majority of companies discussed on Hacker News.

The way to delight your customers is to iterate quickly. The way to achieve great software is also to iterate quickly. That is not a coincidence. Willingness to withstand a little bit of breakage allows companies to move fast. This contributes to an overall _higher_ level of quality, leading not to frequent outages (Facebook does not have frequent outages and failure), but to more robust product.

I am aware of how people build software in more traditional fields (my background is in compilers and static analysis). I am also aware that traditional software development techniques are being eclipsed by those who are willing to throw off the shackles of the past. The "hackday coding methodology" may not be useful to make the code for your car, but the techniques used to build your car are not useful for building a successful SaaS product.

[jessedhillon]

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?

[pbiggar]

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.

[amirmc]

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.

[pbiggar]

"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!

[amirmc]

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.