In the case you mentioned, with a clear perception of a problem being fixable within a nights work, I of course agree, that's the time to keep on working. But

In the case you mentioned, with a clear perception of a problem being fixable within a nights work, I of course agree, that's the time to keep on working. But I think we will probably disagree on the right time to call it quits. In my book, that is when the situation is more diffuse, like the hard-to-find bug on a real-time enterprise system with many integrations, and your team is fatigued, having spent 20 hours already trying to fix it, with no clear outlook on when it will be done. If you keep on at this point, you run the very real risk of turning a manageable bonfire in the kitchen into a wildfire that takes down the whole neighborhood. I.e. direct contra-productivity in the form of unintended side consequences and breakages introduced by bleary-eyed programmers. Such issues can often end up putting the system down for even longer than it otherwise would be. In a standard, non-live development situation, the effect will be less immediate, like slipped schedules and high defect counts, sometimes turning into the classical "deathmarch" project where there is a constant feeling of one step forward, two steps back. The risk and impact of course varies a lot from situation to situation, so just to be clear I am not categorically stating anything here: Calculated risks can be okay, and everything has exceptions, especially when it is a production / sysops crisis versus a development deadline crisis.