[tombert]

I hate that the Move Fast And Break Shit motto is so demonized now.

I think if what you’re working on is very low stakes, e.g. the initial versions of Facebook, or an AI music generator app, and maybe even marketing, it’s not unreasonable to try and move really quickly because the likelihood of real damage is pretty low.

Of course when you’re dealing with money or social security data or medical stuff, it’s different; that stuff is very much “move slow and don’t break anything!”

[daveguy]

To be fair. "Move Fast and Break Shit" was a garbage motto to begin with. Maybe better to be at least slow enough to realize the consequences of a broken app. If you're moving too fast and breaking too much shit, you won't know you have a suicide-assitance app until it's too late. So, it was a garbage motto to begin with and it's about time it's been taken down a notch, in my opinion. How about move fast and test/verify/validate shit instead? That way the entrepreneurs don't have to go full sociopath.

[tombert]

I don’t think that enterprise slowness and “verification” would prevent a suicide assistance application in this particular case, unless they were specifically testing for that which could be missed even with a rigid testing structure.

> How about move fast and test/verify/validate shit instead?

Because that inherently isn’t moving fast.

I don’t completely agree with the “Move Fast And Break Shit” mantra myself, but I think it comes out of genuine frustrations from the enterprise world.

I worked at a BigTechCo [1] in the past, and it felt like I would spend twenty minutes doing a ticket, and it would take two days for everyone to “verify” my PR. Even doing a quick fix for a null pointer exception can take three or four days to get deployed as a result of this. The stuff I was working on was not high stakes. I wasn’t dealing with money or medicine or pacemakers or weather analysis or anything like that.

The Move Fast and Break Shit stuff comes as a bit of an overcorrection on this, but I think fundamentally the idea is that a lot of this stuff really isn’t that important, and it’s better to just deploy something that “probably works” and fix problems as they happen.

[1] It’s not too hard to find based on my post history but I politely ask you do not post specifics here.

[gibbitz]

> but I think it comes out of genuine frustrations from the enterprise world.

Yet politicians continue to act like the government should operate like a business and for some reason all of us working in corporate America think this is a good idea...

[tombert]

You won't catch me saying that. I have grown a pretty distilled and pure cynicism for corporate America.

The federal government certainly isn't perfect but the solution is not to try and make it more like the corporate dystopia.

[daveguy]

1) a well designed test suite does run fast.

2) they very easily could have determined how readily the bot talks about suicide under guise of "character development" or whatever they call that very well known jailbreak.

3) move fast and break shit with social media and AI is sociopathic. Better to save it for the todo apps. At this point MFABS is just another way to say unprofessional software engineering in favor of more profit.

[tombert]

> a well designed test suite does run fast

Not what I meant. Even if the test suite itself executed instantly, which it doesn't and it's ridiculous to assume that test suites are "well designed" in the average case, it's still the bureaucratic slow nightmare of "enterprise development".

> they very easily could have determined how readily the bot talks about suicide under guise of "character development" or whatever they call that very well known jailbreak.

Even if it could be detected it is absolutely in no way implied, or even suggested, that having a bureaucratic enterprise test suite would have detected that. That's just an assertion that you're making.

> move fast and break shit with social media and AI is sociopathic.

As I said, I don't completely agree with the mantra. I just said that it comes out of a legitimate frustration with how awful enterprise development can be.

> At this point MFABS is just another way to say unprofessional software engineering in favor of more profit.

I don't disagree with this, hence why I said it's ok for stuff that's low-stakes. If you're working on something like, for example, a music recommendation system, and the system accidentally plays a Taylor Swift song instead of Metallica, and this happens because some software wasn't properly tested, it really isn't a big deal, somehow the metal-head will survive.

"Professional" and "unprofessional" aren't well defined terms. There are times when it's ok to half-ass something because it's better to just get something that works instead of getting something that's perfect. There are lots of applications, maybe even most applications, where that doesn't apply and it's better to try an strive for perfection, but it is intellectually dishonest to pretend that everything silicon valley is working on is high-stakes and that striving for perfection immediately is actually beneficial.

I would love a universe where everyone designed everything in TLA+ (or something similar) before building software, this would make me irrationally happy, but I understand that it's not realistic or even reasonable to do this for every application.

[lesuorac]

Meh, its fine for a company to be honest about their development process.

Most companies nowendays claim to be "Move Fast and don't break shit" when in reality they're "Move Fast and Break Shit". See the whole CrowdStrike debacle [1], both sides of that lawsuit are in the wrong here. Crowdstrike shouldn't've down a rapid deployment like that and Delta wasn't supposed to use the Falcon Agent on those systems. They both choose to move fast without verification and broke stuff. Neither of them are going to say that "Move Fast and Break Shit" is their style but it is!

[1]: https://en.wikipedia.org/wiki/Delta_Air_Lines_v._Crowdstrike