I'm reminded of a blog post I once read, which annoyingly I now cannot find, on how the job of a library maintainer is to not break the API. If you break the API, you've failed at your job. This mindset makes more sense than treating API breakages as a routine case-by-case decision. As the article puts it, breaking changes are breaking the library's commitments. (The library/service distinction doesn't matter much here.)

I remember that same old blog post also lamented overhearing a conversation in which a developer bragged about how their idea for a change was so good that everyone agreed to break the library API to implement it. This reminds me of how a startup being 'highly disruptive' is sometimes fetishised as an end in itself, but of course it's even worse than that: they're celebrating undermining the library's dependability.

sounds kind of like this famous linus rant: https://lkml.org/lkml/2012/12/23/75

Linus is 100% correct here.

Too often it’s “a user error”.. no, it’s a platform/developer/provider ak lower level error or mark of laziness

Is he always like that? That's toxic af

Complaints about "toxic" are a screen to hide the fact that you can't say "incorrect".

He has toned it down significantly in the last few years.

"Yes."

Agreed, that is probably why you wind up with a lot of versioned Microsoft C++ runtime installers on your computer, but damn it at least the reliant software works as intended.

A library being dependably bad is not good. Sometimes changes really are good enough to break an api. It does take a significant amount of communication to do this without pissing people off, though.

Microsoft is definitely treating their developers well.

I was exposed to this firsthand yesterday when I cloned the [ShareX](https://github.com/ShareX/ShareX) project to take a look at a problem I was encountering.

Literally all I had to do was install Visual Studio Community, click the “Open in Visual Studio” button on Github, wait a few minutes to install the C# runtime that Visual Studio automatically prompted me to install, and click “Run”.

5 minutes was all it took to be writing code for that project and it makes me want to get into the .Net ecosystem more.

Chiming in: just did the same with Docu, HTML documentation generator from C# XML doc https://github.com/jagregory/docu

Project code did not change much since 2010. It even has bits of IE 9 support.

Try to keep up with Android development and Play Store policies...

I stopped publishing own apps on the Play Store, and unpublished all the one that I had, because of the stress and the time used just to follow the damn policies.

As an Android engineer, I'm not sure what you're talking about. There was a push to get people to move to the new permission model, but I believe that's still optional so long as you're willing to suffer with old SDKs

They're making it mandatory to constantly bump your targetSDK.

They're adding new requirements one has to follow in order to get access to certain permissions.

They're updating their content rules which make anything with user content very very difficult and might just kill your app one day.

They're updating graphics and icon requirements rather often.

It's a rather big amount of work if your app isn't super simple and relies on functionality they change.

> Win32 binaries I wrote in college still run on Win 10.

Hell they said they were dropping support for VB6 in Windows 8 if I remember correctly, but I'm pretty damn sure I can still install the IDE, I know VB6 apps aren't broken for darn sure since I've re-downloaded some old ones I used to use.

Not only that I had to go and update some zombie app I've left running on App Engine that I haven't touched in years because I got some email saying "we have changed something, and your app is running Python blah blah and that runtime will blah blah soon. Please log into the Cloud Console..."

I guess you can't just set it and forget it on Google Cloud either even though everything was legit fine at time of deployment; I mean come on, it's a simple Python Rest API, what you want me to do 7 years later? xD

Unfortunately I understand that Azure is not exactly what one would call "mature software". I have a colleague who's been using it for a few months, and he complains about it constantly. He's had to submit a couple of pull requests for somewhat silly issues like string escaping not working properly.

I don't have the same issues as your colleague. I've been using Azure for 8 years and rarely run into any issues. Maybe his issues isn't with Azure.

I just started using it, and ARM template just silently ignores misplaced resources (wrong JSON section). Spent 2 days debugging it.

I have heard similar from more than one person. Maybe it depends on the services you use.

Or, perhaps, the particular SDK you use to access their API?

Same, 8 year user. No real issues to complain about.

used azure to host an aspnet website, azure sql, and azure redis. everything worked pretty nicely, we made money and had a quality product reliably on the web with a small team. this was 2 years ago.

Microsoft under Nadella is infinitely more interesting than Google is under it’s current scourge of bean counters and MBA-graduates that seem to be running the place...

It’s not entirely comparable, but Google is basically in their “Steve Balmer”-phase.

Hopefully they can eventually get someone with competence and actual domain knowledge, and not some asshole who’s been taught they can lead whatever because they’re been “educated” to lead..

That's because product management at Google is non-existent. Yeah there's a lot of people called "product manager" but what they do ain't it.

People have to realize, that software is not done when written.

Software makes the fabric between everything in our lifes. It brought us tones of innovation; It is one of the biggest enabler, innovation drivers and tool we have. It is one of the complexest and cheapest tools we have.

You know what happens with software which is stoped being worked on?

Very old, unflexible Cobolt Software on Mainframe systems in banking systems. Guess why your bank is so antiinnovation?

Security holes

'Legacy hell'

We just need to do less Software and better Software.

People realize this, especially on HN. The post is referring to deprecations. You can patch security vulnerabilities and move a product forward without deprecations. Google does it well with Go.

Deprecation is too kind of a word. Traditionally deprecated means that it is no longer a best practice/canonical. It's nice to see deprecated flags when building new code because you know you found an out of date bit of documentation and you should look at what may be a better approach.

Deprecated APIs, functions, etc, in many orgs hang around forever. They might not be ideal, but they still work for code written before (or even code written after that might have some perverse reason).

Google (outside of Android) doesn't deprecate, they rip it out. It makes things easier for them, as this post details at length, but it makes it harder for the rest of the universe.

Until Go is deprecated in favor of Kotlin (as Kotlin is experimenting with server-side)

Its the same thing.

Versioning and backwards compatibility costs a ton of money and blocks your innovation.

Legacy hell comes often enough also from dependencies you can't get rid of anymore...