Because I have first hand experience on a good swath of the search stack. Shuttering a standalone product is mostly an organizational effort. Removing a search feature is a coding adventure. One feature is sprinkled across the code base like pixie dust, magically becoming a count down timer to serve a users query. It is simply too high a cost to go and remove a single feature. It is also highly unlikely that leadership would approve bricking a swath of search features for technical reasons, it is just not in the organizational culture.

It's a bug that'll be fixed when someone notices.

Can you explain how a timer could be complex, apart from impressively bad engineering?

First you need to understand that the intent of the query string is to set a timer. Human language is ambiguous so there can be many competing interpretations.

Then you have to take all the intentions and ask backends to fulfill them with their actual results

Then you sort the result by the correct order for the user.

Then you need to render the search page. At this points some results may not want to be present anymore because they are not the top result.

That's a 50'000 foot approximation of what happens when you query Google. The process has tons more complexity as you zoom in.

It is amazing engineering, but probably not the first way you'd go about implementing a count down timer.

I am honestly confused how people have so little experience and empathy for engineering, even on a forum like this.

Do you actually work somewhere where you're providing one of the most-used services in the world and it's held together by "trivial shell scripts"? Do you really think people at Google are so bad at their jobs that they went "Well, this is 4 lines of Bash, but I could make this needlessly complex for no reason" It's not as if they're the height of engineering, but the arrogance to just assume that there's no reasonable factors that may have not lead them to doing something more simply is so foreign to me.

It’s not that I lack empathy - I know many of those folks, and I’d work there if I wanted to. It’s just that an empathy towards Lenin bust factory workers doesn’t make their hard work any more useful.

You’re confused, because you got it exactly backwards - most technical people who work this kind of jobs lack the big picture required to realize that the vast majority of their work is just technological debt. And some others that do get it also understand the business part - and while this overcomplication is bad technologically and user-wise, it might make sense to business.

Also, let me remind you that those “most-used services” are generally of quite poor quality, both in terms of reliability and user experience. There are services that do matter - ads and tracking - and I’m guessing those are more cared about, but I’m not talking about them.

I just don't think this meshes with any of my experience talking with people who work at places like Google. Your argument keeps being "but Google is bad and what it makes is useless, therefore the code behind it is terrible and made by people who can't think".

Working at places with a lot of tech debt, or where you're creating tech debt knowingly is just the state of the industry at almost every company. I've never met a developer who doesn't see that, let alone "most technical people". This entire thread is full of current and ex-Google employees saying essentially "Yea, this is probably because of tech debt and sprawl". If you deigned to go work at Google some day, it's not as if you'd be able to just untangle all of it with a few bash scripts even if they made you King of Google.

I have no love for Google's products myself, but it's mystifying to me when you let your clear distaste for some of their decisions and priority cloud your view of what they've created and maintain. When was the last time Google Search or Gmail was unreliable for more than an hour? Maybe once in the last 2 years? That doesn't even come close to any objective measurement of "quite poor ... reliability". Even if you and I seemingly don't like their services, it's just willfully blind to say that what they provide isn't useful to millions or billions of people.

My argument keeps being “if you have an incredibly complex mechanism working at best marginally worse than an extremely simple mechanism, then something’s not right with your design”. Regarding Google employees, what I wrote is close to the exact opposite of what you claim above, so…

>tech debt is everywhere

The point isn’t that there’s a lot of debt there - it’s about the speed of adding new debt vs actual functionality, which in turn comes from mistaking adding complexity for improvement.

>unreliable for more than hour

You’re talking about availability, aka “appearing to work”. What I’m talking about is reliability, aka “does it actually work”. Not does it fail for more than hour at a time, but how often does it fail at all. You need to count the forced reloads we’ve all learned to do automatically at this point. And I’d definitely remember last time mutt(1) failed on me, and I honestly don’t; I’m guessing sometime last decade. Except intermittent IMAP connection problems… to GMail. (For which mutt already got workarounds; it’s not like anyone expects Google to fix their servers.)

(And sure, my mutt was configured some eight laptops ago, but it just so happens it’s the same for my Gmail account.)

The point is that it's not really the timer that's complex. It's the path taken to determine that a timer should be displayed in response to a search query. The timer itself is presumably fairly trivial.

Because the complexity isn't in the timer, but in adding it to an otherwise massive pile of code that makes the rest of everything run. It's like if you're building a hotel with hundreds of rooms and you decide every room should have an installed alarm clock. The clock mechanism itself you can buy cheaply, but if you want it to look good, match your decor, and not have wires exposed, it's suddenly harder.

If it was just a single-use page on timer.google.com, you'd be totally right. But having Search know that "5 minute timer" should show a timer, but "Egg timer" should show a picture of a product, and "new year's eve countdown" should probably give you a timer/countdown, but only on some days of the year, and on others it should be to videos of last year's.

In your example this “decor” is an improvement: it makes using it nicer. Can you tell me how this “fantastic engineering” makes google timer nicer? Because to me it isn’t quite obvious; what is obvious is how it makes it worse, by lowering reliability and invading privacy.

I don't even know what you're trying to say here? If anything, the "decor" in my hotel room metaphor was a metaphor for... decor? I could make a timer that outputs ASCII text for the countdown, but if I put that as the first result in a Google Search results page, it would look weird and out of place. As far as I know, Google having consistent CSS doesn't lower their reliability and invade my privacy.

There was never a Google Timer that wasn't a part of search, so it always was going to need to integrate with search. If you just want a website to load with a timer, there's plenty of other options.

I get it, you don't like Google, you think they make products that are bad for people and privacy. All of that I mostly agree with. That's a set of complaints that, as far as I can tell, have no relation to if Google Search still has a timer feature. Even if they stripped out all of the tracking and whatever you think is making them not have "reliability", the remaining search engine would still be an impressive and hard to integrate with bit of code. You see this in the cost to develop and run services like Kagi or the belated Runnaroo search engine, both of which were far better about personal privacy and, amusingly, less reliable than Google.

So it takes fantastic engineering to fetch a value from a single input box and then echo a string with some CSS around it? :-D

Once again - instead of reasoning about the usual piece of the stack try to understand the whole thing - from users’ intent to use it all the way to the timer going off. This is a tiny bit of a 10£ Casio functionality. You shouldn’t need datacentres to replicate that.

> both of which were far better about personal privacy and, amusingly, less reliable than Google.

Less reliable in what way?

In every way. Any Google service can fail for a myriad of reasons, from internet connection problems to some random failure of one of billion fantastic engineering pieces involved, to Google blocking your account for whatever reason, to Google deprecating the service.

Compare this with failure modes for the date(1) utility, or a Casio watch, or the default one in your phone.

It might be more illustrative to use some more complicated service. Compared with VLC, reliability of YouTube is a joke.

I am afraid I am not following the train of thought. If any Google service can fail at any time, how is some other service less reliable than Google?

Sigh, sorry, it should read “more reliable”, or “less prone to failure”; somehow failed to notice this in my previous comment.

A lot of these "Falsehoods programmers believe about time" apply to making a timer: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

Honestly, that’s another argument against Google timer: you can’t assume it’s correct, because you don’t have any insight into its internal operation. Most people assume it can’t be bad, because Google is big and rich and popular, but both theory (argument from authority) and experience show it doesn’t hold water.