Yeah, I'd bet this is the case. They just don't have anything to gain by turning it off. Do they?

Well, it is strictly speaking an API, and we all know how Saint Car feels about APIs...

(I would not be surprised if it was literally this, some sort of absurdist "no exceptions" aspect to the API-killing diktat.)

Could be some really awful ploy to get more people to pay for Twitter Blue.

Am half expecting some serious security related bug has been found in their SSO, thus them turning it off without warning until it's resolved. But, who knows...

To expect that, you would have to assume a level of responsibility to end users that I find highly unlikely at Twitter right now.

What the heck, someone flagged this?

I’m mostly impressed how shite the ”webscale” codebase is, if everything bursts to flame the moment the programmers stop babying it. Considering how many man-hours they’ve poured into the product, you’d think it would be somewhat bug free

Come back in a few years, when you’ve written software at this scale and at this velocity. I’m interested to hear what the experience has to teach you, and to see how you grow as an engineer beyond this kind of uninformed nonsense.

I'm not the one you're replying to, but I've worked on software, for far more critical infrastructure than Twitter, that has run unchanged for over 3 decades.

You only hear about the failures. You don't hear about the systems that keep on working.

and to see how you grow as an engineer beyond this kind of uninformed nonsense.

In other words, "grow as an engineer" means "parroting the lies that keep you employed"? As the saying goes, "it is difficult to get a man to understand something, when his salary depends on his not understanding it". And that explains the sad state of most "modern" software.

The comment specifically asked for advice on software that changed with the same velocity. It’s the rolling out changes part that adds the interesting risk.

> that has run unchanged

Exactly. Software that changes as frequently as something like a Twitter (or anything of that ilk) never has the chance to reach that kind of stability. Your thirty-year system wouldn’t have the track record it does under the same set of conditions.

> In other words, "grow as an engineer" means "parroting the lies that keep you employed"?

I’m not sure what kind of leap you’re making, but it seems breathtaking.

In any case, you’ve clearly had the privilege of working on software under vastly different constraints and timeframes. That sounds fun, and interesting, but it’s comparing apples to oranges.

As a response to all the sibling comments, what need is there for Twitter to change every 3 days!?

“Need” is a strong word. I guess it doesn’t need to change. But new features == new opportunities to make money, if nothing else.

”There’s a bug, so we should rewrite the entire thing”

Seems a lot more straightforward than running software that changes every 3 days.

> ... has run unchanged for over 3 decades.

That's a good point.

For the software you worked on, is there some kind of public case story or similar that people can be pointed at to learn more?

I wouldn't exactly characterize this as "the moment" that it stops being babied. Twitter agreed to the sale a year ago, and the sale was completed last October, about 5 months ago. Plenty of time to accidentally break a dependency somewhere, even if they're not actively developing or maintaining it.

Do you have any tips for making software that is bugfree and can run indefinitely without support?

I read on HN that "no code is best code" !

Or it could be the fact that Elon is trying to have his employees work 24/7 adding whatever new ideas he has for the product and "move fast" is causing the "and break things".

Twitter was actually remarkably and usually stable. Note the past tense, it became unstable now after months of Musk ownership. You know, after he demanded fast changes.

It could be a ruse for folks to get rehired.