311–320 of 567 posts
Earlier quoted context omitted.
They might not be wrong. Engineers who could be maintaining mildly profitable products could be invented new products that have some percentage chance of being much more profitable. If someone did the math and said the expected value of "engineer working on new projects" was bigger than the expected value of of the the profits of an existing project divided by the number of engineers needed to maintain it, then it'd…
> Engineers...could be invent[ing] new products that have some percentage chance of being much more profitable Doubtful. The successful products to come out of Google are Search, GMail, and GCP. They bought Adwords, Doubleclick, Android, Youtube, and Nest and Fitbit, I suppose. GCP is their only recent win, but it's a me-too late entrant in a market Google should have invented .
Earlier quoted context omitted.
> It seems like any company would have to be crazy to want to depend on any new Google service for anything important. Companies depend heavily on AdWords, gSuite, and Cloud and all three continue to grow. The reputation for canceling projects which aren't working may matter to consumers, but I haven't seen anyone in business mention it in their purchasing decisions.
It might be your vantage point. For several companies I personally engage with this has absolutely been a point of discussion for Gsuite vs O365.
So I don't completely understand why you need a proprietary Google "cloud" service that they can sunset some years later and break. When I heard about this I wondered why someone can't build a consumer-friendly solution on these older protocols.
Of course, printing itself is less relevant than it was 20 years ago, so it's not exactly a booming industry.
Earlier quoted context omitted.
So this works in theory until there is a really bad bug in some part of the code base and there is no one who knows how to fix it. Or it breaks some kind of migration plan. Or it is embedded somewhere on some architecture that slows down an important projects development. or makes an application incompatible with a future OS If they’re not going to keep a team dedicated to keeping it alive, then you get into a situat…
> So this works in theory until there is a really bad bug in some part of the code base and there is no one who knows how to fix it. 10 years of production usage tends to have hammered out all the "really bad bugs." Sure it's possible that something goes wrong, but it's also extremely unlikely that it does unless something in it changes. Which, if you freeze it & silo it off, doesn't really happen. A huge amount of s…
Earlier quoted context omitted.
Counter-argument: Just let it sit there and keep working? Outside of security patches, if there even are any, there's always the option of "just stop touching it." After all, the whole pitch of elastic compute is you only pay for what you use. It's not like resources are being freed up for other things here. The software industry is always on this treadmill of churn, leading to stable products continuing to have a co…
So this works in theory until there is a really bad bug in some part of the code base and there is no one who knows how to fix it. Or it breaks some kind of migration plan. Or it is embedded somewhere on some architecture that slows down an important projects development. or makes an application incompatible with a future OS If they’re not going to keep a team dedicated to keeping it alive, then you get into a situat…
The product has been around 10 years, and they're giving over a year notice before killing it. Sure, Google kills off another product... But the comments here are a bit silly.
Counter-argument: Just let it sit there and keep working? Outside of security patches, if there even are any, there's always the option of "just stop touching it." After all, the whole pitch of elastic compute is you only pay for what you use. It's not like resources are being freed up for other things here. The software industry is always on this treadmill of churn, leading to stable products continuing to have a co…
Sounds simple but sometimes it is not so easy.
E.g. it might be written in Python 2 for all we know. Should they leave it on Python 2 with zero security updates, or invest lots of time porting to python 3?
Obviously there will likely be a million other internal examples of the python 2 to 3 migration that we don't know about.
Earlier quoted context omitted.
This is the right move though because moving towards "Driverless printing" will solve the overall problem in a simpler way: https://openprinting.github.io/driverless/ Google is pro-adapting to change. And it is painful but it is usually the right thing.
Driverless printing has been "the future" for over a decade now (I remember hearing much about it back in 2006 or so), and a concept for two decades. Microsoft first filed the patent back in 1999 [0]. The only thing that's changed is the patent is now expired (as near as I can tell), thus opening the door a bit wider for adoption. But, as with many things, "I'll believe it when I see it." [0] https://patents.google.c…
Earlier quoted context omitted.
Revenue generated from charging for products such as this would be probably chump change for Google. Google is a mass market company thus chump change is irrelevant to them. Plus they are used to operating at a scale by providing products for free. Consumers are used to Google providing products for free. Thus it’s jarring for a lot of users to suddenly pay for basic functionality. Enterprises probably don’t need thi…
But Google isn’t Google anymore. They’re Google, an Alphabet Company. So there should be more space for this. The problem is that Page and Brin, the authors of the perverse incentives at Google, are still in charge. Alphabet would have been a great place to bring in some people who are good at maintaining projects. Hell Google could learn a thing or two via osmosis about efficiency from them. Maybe cut the ageist bul…
Hey, they're more than happy to hire anyone who can pass a four-hour CS undergrad final as a mid-level engineer, regardless of age or experience.