One Compile A Day
A recent blog post by Ian Bogost (The Virtues of Long Compiles) has me thinking once again about the trouble with fast compiles. How would you program differently if you could only compile your project once an hour or perhaps once a day? Actually its more complicated than that. What would you do between compiles? Would you work on other programs or perhaps new modules for the compiling program? There are risks associated with working on modules that have to work with code that hasn’t actually been tested yet. Would you read the manual or textbook looking for new ideas? (That is one thing that comes up in Ian’s post BTW.) This is a hypothetical or theoretical question for most students today. For some of us old people it means trying to remember how did we do thing back in the day of card readers and line printers.
The first thing I remember is that I put a lot more thought into the code before I hit the compile button. Well actually before I gave the operator my card deck. 
I didn’t compile after each syntax error was corrected for example. Or even some few number of them. I tried pretty darn hard to identify and correct each syntax error that the last compile had reported. The trick here is that one really had to understand what the error was. There was no time to try random changes and see if they worked. One did some analysis and you were always looking for the one fix that would correct several (or many) errors. Forgetting to declare variables was a killer. Today good IDEs (well Visual Studio which is what I use for most everything) help with the syntax errors are you type. Once doesn’t always have to run a full compile to catch the missing variable declaration for example. That doesn’t mean that errors that are a combination of syntax and logic such as bad assignments with mismatches of type always get caught of course. But one doesn’t have to wait for a long compile to catch most syntax errors.
With long wait times between compiles there was also an incentive of sorts to write as much code as possible before submitting to compile. This is not so much a good thing. It is much easier to debug a small piece of code than a large complex piece of code. On the other hand you really wanted to make sure your logic was sound, your interfaces clearly defined, and expectations well mapped out. This may be a win for the fast compile crowd in the long run but I’m open to opinions.
Once one handed in their card deck to the operator there was time before you got the results. Depending on that facility or school that could range from under an hour (the small liberal arts university I attended) to the next day sometime (the larger NYC university my wife attended). So what to do? Sometimes that was time used to prepare test data for when you did get a clean compile. Sometimes it was spent going over the assignment and seeing if anything was missing. Sometimes designing yet another module. Often it was in discussion with others waiting for their run to return. Still other times it was on to some other project for some other subject entirely. In some ways that mental break was a good thing. All in all one did learn some patience. Patience is a noble and necessary virtue for software developers – and other people as well.
The instant edit, compile and run cycle of modern high speed compilers has changed the way we develop code. In many ways for the better but in the process I sometimes fear we have lost something as well. Patience, careful consideration, attention to detail, and maybe solid planning. Back in the card punch days we saw more women in software development than we do today with the fast edit/compile/run system. Coincidence? I wonder. Does today’s way lend itself less to the way women work than the “old way?” I have no idea. I know of no study. But it is something I just happen to wonder about.
[EDIT: See also Eugene Walligford's blog post at "I Love The Stuff You Never See"]
Comments
Anonymous
December 26, 2011
The comment has been removedAnonymous
December 26, 2011
The comment has been removedAnonymous
December 27, 2011
http://xkcd.com/303/ just pictured this the entire article.Anonymous
December 27, 2011
Yes, we all spent more time checking things...Maybe that same paradigm should be applied to the age of spelling correction, since in this posting, there are numerous cases of the wrong word being put in by the spelling correction... Even simple things like really Proof-reading your work seem to be a lost art....It is a good thing that we are a lot better at parsing the meaning, rather than a strict interpretation of the words being used... But none the less, thought provoking.Anonymous
December 27, 2011
Could you compile a bigger font?Anonymous
December 27, 2011
Scott, thanks for pointing out that there were typos. I especially appreciate that you didn't point out where they were so I could have fixed them more quickly. And that you did it in public to maximize my embarrassment. I hope to return the favor some day. Pair of glasses, I increased the font. You may want to also think about upgrading to IE which makes it very easy to increase the size of web pages you are reading. I find that very useful.Anonymous
December 27, 2011
I was in this situation in the early sixties. We got about three compile and test runs in a long day. We used to spend hours "debugging" - each test ended with a memory dump (in octal) and we used to go over it with a fine tooth comb to check that each memory location contained the expected value. The current environment with instant response is much more productive.Anonymous
December 27, 2011
Wow, you're absolutely right, never event thought of it that way. I'm very dependent now on compiling to get the compilers input on errors!Anonymous
December 27, 2011
I use Resharper in Visual Studio and ItelliJ IDEA for Java so I don't have to compile to see problems in my code.Anonymous
December 27, 2011
In some cases, times haven't changed. We have two build machines, four products, and multiple branches of each product. Some product attributes can only be correctly tested through a full build. Build times range from 45 minutes to two hours, and we typically get in four or five builds a day. Depending on priorities, that means it may take a day to turn around a build for a given branch.Anonymous
December 27, 2011
The comment has been removedAnonymous
January 02, 2012
Several years ago I was confronted with the same situation. I was acustomed to rapid ECLG cycles. In this C++ project a link run took almost one hour. The largest problem was that I had to do changes in unknown insufficient documented obect oriented code. So a lot of activity was try and error. What I did was debugging the code and find out what it did and later I found a way to incrementally link, what brought it down to a few minutes.Anonymous
January 15, 2012
The comment has been removed