I wonder if this is another indication that some of the old practices from "back in the day" will come back, in some unexpected form.
For example: I remember, back in the day, that in order to compile, I had to submit the compilation job to a batch queue running on a separate server. Usually, you got your "success" or "failure" message back within a half-hour.
(Similarly, print jobs printed to a device in a locked room, and an "operator" (remember those?) would deliver the printout to your desk, usually within a half-hour.)
Needless to say, one tended to be pretty damn certain that the code was clean and correct before attempting to compile.
As Samuel Johnson said, "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully."
That's an interesting point. I guess the compilation job queue, which itself sounds similar to punch cards through a mainframe, has its modern equivalent in running large MapReduce jobs or load tests on EC2... not something I would want to repeat too often during the dev cycle :-)
For example: I remember, back in the day, that in order to compile, I had to submit the compilation job to a batch queue running on a separate server. Usually, you got your "success" or "failure" message back within a half-hour.
(Similarly, print jobs printed to a device in a locked room, and an "operator" (remember those?) would deliver the printout to your desk, usually within a half-hour.)
Needless to say, one tended to be pretty damn certain that the code was clean and correct before attempting to compile.
As Samuel Johnson said, "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully."