> it just causes developer busy work with no additional value.
Anyone remotely familiar with Google as a third party developer will notice the pattern: this will ramp up until it is almost your entire job simply dealing with their changes, most of which will be not-quite-actual-fixes to their previous round of changes.
This is not unique to Google, but it is a strategy employed to slow down development at other companies, and so help preserve the moat.
Old-timers who date back to when Joel Spolsky's early musings on the business of software development were fixtures on the HN front page will remember him using the phrase "fire and motion" for Microsoft's old strategy of constantly making changes so that everyone trying to keep up was—like the Red Queen—running as fast as they could but not getting anywhere.
> Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can’t move forward?
> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP.
—Joel Spolsky, "Fire and Motion," 2002
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
There’s a solution to the Fermi paradox somewhere in this string of comments.
> ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET
Notably all of these still work, even if not getting new updates.
> it is a strategy employed to slow down development at other companies, and so help preserve the moat.
Worked at Google for 7 years, and your post reminds me it is time to share a secret: it is Koyaanisqatsi* and people's base instincts unbridled, no more. There is no quicker route to irrelevancy than being the person who cares about something from last years OKRs.
* to be clear, s/Koyaanisqatsi/too big to exist healthily and yet it does exist -- edited this in, after I realized it's unclear even if you watched the movie and know the translation of the word
If they actually incentivized a group to support stability and continuity among enterprise customers, they would probably be able to diversify their revenue away from ads. Microsoft understands this…
The real sick thing is it doesn't matter, right? Like we're commenting on an article about how they won the day yesterday and Cloud revenue continues to skyrocket.
To be clear, I agree with you, and am puzzled by the lack of consequences from the real world for the stuff I saw. But that was always the mystery of Google to me, in a nutshell: How can we keep getting away with this?
> How can we keep getting away with this?
A large part of that is the Google-are-super-geniuses PR effort. Anyone pointing out that Google's products don't reflect this to their boss faces having their own credibility reduced instead.
If it's so obvious, and Google supposedly know this internally, and can obviously tell by others that some are avoiding Google because they're fast at sunsetting services, why are they not doing anything about it?
Imaginary conversation between an honest VP and earnest year 0 me, here's what the VP says: "We definitely care about deprecations: now tell me how to accomplish that with Sundar's Focus™* Agenda over the last 2 years"
* no net headcount increases, random firings, and any new headcount should be overseas. i.e. we have the same # of people we did in 2021 with 50% more to do.
Because it’s not meaningfully hurting their bottom line.
I used to think that made sense (as sibling mentions, Spolsky's "fire and motion" thesis)... until I worked at large-ish tech company whose internal platforms also kept doing this. Heck, the platform I owned also underwent a couple cycles of this. And so a large part of our work was just doing the Red Queen's race of deprecations and migrations.
So it was definitely not "fire and motion," as there was no competition. I think platforms genuinely need to evolve as new use-cases onboard and technology progresses, and so the assumptions underpinning the platform's design and architecture no longer hold.
However, I do think a small part of the problem was also PDD: "Promotion Driven Development."