> Otherwise, theoretically you can "overwork" i.e. (work more than standard 40 hour weeks or some standard of work hours) whatever without compromise

That's simply not true. Humans aren't machines. Productivity falls off a cliff after 50 hours, and after 55 you may as well not even be in the office. There are diminishing returns with "overwork"ing.

[0] https://siepr.stanford.edu/research/publications/productivit...

On paper, sure. In practice, having people overworked leads to compromises you never intend to make, simply due to exhaustion and burden clouding judgement values.

Thats a problem of process where errors are caught.

It makes things more inefficient, but it doesn't compromise final quality assuming issues are found and addressed.

No quality control process can reliably catch software errors. That's why it's generally better to prevent errors rather than catching and fixing.

Every software error? True. But essentially every software error, especially errors of significance? Untrue. The Space Shuttle control software was famous for its rigorous process control, and deliberately written in a language difficult to introduce bugs in. Over decades of development and 420,000 total lines of code, it appears that a total of 17 bugs ever made it into software used during a launch, with an average of about 1 bug at a time existing in the codebase. Processes to prevent errors from being introduced played a huge part in this, but the comprehensive verification and simulation process was also necessary to achieve such a low defect rate.

https://www.fastcompany.com/28121/they-write-right-stuff

The NASA Manager’s Handbook for Software Development from 1990 is a great resource. We have better techniques for some areas now but most of it still holds up.

https://sw-eng.larc.nasa.gov/supporting-products/archive-of-...

That's amazing work and dedication.

But I feel it fair to consider an organization like NASA as an exemption from the norm. This level of detailed error catching doesn't make sense for, say, a facebook clone startup.

That said, someone should send this comment to a Tesla engineer.

Why does "normal working hours" solve the "reliably catch software errors" issue.

so the solution to overwork is more work?

yes? That was literally my point, its less efficient, but can be okay in terms of final output.

Not sure that holds up to scrutiny, as often when people are tired and overworked their output can dip negative.

It's fine for a few days, but after that it's a false economy.

So now you have to do extra work to catch errors, which is a compromise in its own right.

hence the inefficiency comment?

That makes sense, but the point is that it's still a compromise. Even if we're saying that people can work overtime to get things done, there's typically diminishing returns on each additional hour worked, and still no guarantee that quality hasn't been impacted.

If you ask people to work 12 hour days instead of 8 days, does each day provide 8 hours worth of work, 12 hours worth of work, or another value? Can we reliably say that any problems arising from working over 12 hour days are caught and handled at the same level as they would be if people were working 8 hour days?