Who or what decided conventional network timeout length?

Your co-worker is totally wrong about the relationship between timeouts and user experience. Sure, the user would like a response within a second, but they want a successful response. Changing the timeout to a second doesn't help with that. I'd rather have an application that gives me what I want within three seconds than one that tells me within a second that I can't get what I want.

Your criterion should be: Set the timeout to a value x, so that it is very unlikely that the server will reply at all if it hasn't replied within x seconds. If you set it higher that doesn't help, if you set it lower you will miss out on valid responses from the server.

If you have server requests where you know that the user will be waiting: Send the request and start a timer. If the request doesn't respond within say a second, show a user interface that shows the app is busy and has a cancel button. If the request replies, remove that user interface (but leave it up for at least half a second to avoid "flashing" if a request takes exactly 1.1 seconds). If the user presses "Cancel", cancel the request if you can, make sure that any response that might arrive is ignored (when I cancel an operation, I expect it to be cancelled). You may display an error if you get a timeout after 60 seconds.

And if you have an operation that consists of multiple requests, treat it as one unit.

There have been articles regarding response times in order for us to have an acceptable delay from a psychological perspective.

Supposedly 0.1 seconds feels instantaneous for a user, after which the delay is noticeable.

1 second is the most amount of delay you can have where the user doesn't feel interrupted by the delay.

10 seconds is supposedly the maximum amount for a user's attention to be retained, after which users tend to want to do something else in the meantime.

Though I've never heard of 30 seconds used as any particular metric or "standard" waiting time, though I do see it used often.

Hope that helps!

I'd also like to refer to the NNGroup article @Neil posted. However, enforcing a timeout just for the sake of believing that it will heighten the user experience is beyond foolish.

Fast requests heighten the user experience, not timeouts generating error messages.

Saying something along the lines of "The request timed out, try again." is not likely at all to create any happy users. In fact it's likely going to create more infuriation since your job is to make sure that the request works properly. This is to say that the timeout has not increased the user experience in any conceivable way.

Now, let's move on to another area: What happens if the requests actually start slowing down due to something very simple such as increased load on the servers? Your users will be fine so long as a request takes less than one second.

What happens if they start taking more than one second? Well, all of a sudden you have a lot of users with requests which are timing out - And they are seeing error messages which are beyond their control to deal with. What happens when requests start timing out? From my personal experience people start refreshing/clicking buttons a lot. This is very likely to only heighten your load problems.

The question becomes: what's a good timeout value and how can you determine one from data rather than feeling like you're shooting in the dark?

This depends a lot on the request. Specifically, is it logical that a request may take a lot of time? Users are often willing to wait a while for things they expect to take time. Generating a report seems like a typical task where one might expect a delay of at least a few seconds but in these cases you can typically help the user anticipate some wait.

As a finishing point, I think setting 1 second as an ambition for the average request time to achieve is great but don't impose such an arbitrary rule upon your users.