This reminds me of a particular instant at the 1977 ACM event (I believe, long time ago so it could have been a year later). The typical program, back then, set two time limits, a soft limit and a hard limit. After finishing an iteration, if the program had passed the soft limit, the search terminated and the best move found was played. If it had not passed the soft limit the search continued. If, at any time, during the middle of an iteration, the hard limit was reached, the search was terminated and the best move found so far was played immediately.
I was watching a game between chess 4.x and somebody (do not remember who) where at iteration N, they finished close to the soft time limit, but not over, so they started a new iteration. As they gave their analysis to David Levy on the stage, he looked and said, "wait a minute, that move loses, here's why." Slate was pretty sure that 4.x could see that. But back then nobody displayed any search output until the end of the iteration, or the final PV when the search times out. So neither Slate nor Atkin knew whether the PV score had dropped, nor did they know whether or not they had changed their mind. Hence, they were bouncing around like two kids worried about (a) did it see the problem with the current best move? (b) had it already found something better? (c) If not, would it find something better before time ran out. Watching that almost nervous breakdown led me to two ideas.
As Murray Campbell and I were talking (my game was over) I mentioned "you know, I display the PV/score/etc at the end of each iteration, but it is an easy change to move that code up so that the PV is displayed whenever it changed." He thought that was an excellent idea. I made the change, fixed a couple of bugs (the PV now has to be displayed in the search, rather than in iterate.c) and we agreed that this was a quantum leap forward for operator sanity, because now we knew what was going on. I thought a bit longer and concluded "if the score drops a lot, why sit around worrying about whether I will find a better move before time runs out, why not just increase the time limit to guarantee that we have a chance to solve whatever problem the best move so far has?" I made that change and the rest is history. I explained the idea later in the event, wrote it up for the JICCA (along with another idea we came up with later, that of using more time right out of book to make sure we 'understood' what was happening since there are some difficult gambits to deal with.) The paper "Using Time Wisely" was published, and one dark chapter of computer chess was closed forever.
My move-by-change output format has not changed in almost 35 years since, since it makes so much sense. Ditto for time overflow and using more time right out of book. The funny thing was the changes were less about making the program play better and more about helping the operator keep his sanity, although the time-overflow did make a difference in Elo...
