Limits of Programmer Productivity: A lesson from Fred Brooks
My first year at university was the last year studends had to use punched cards.<p>Your programming workflow was:<p>1) write your complete program on paper<p>2) grab a box of fresh punch cards, find an empty and functioning card punch and type out your complete program onto cards.<p>3) very carefully pack them and walk them over to a card reader. Yes. I saw on more than one occasion grown men brought to tears because they dropped a box of cards scattering them across the floor and they would have to spend many hours sorting them.<p>4) stand in the queue at the reader waiting for your turn to read in the cards. In some places you did this yourself. In others you had to hand your cards to an operator that controlled the reader.<p>5) if you were in the main programming room of the datacenter, you would now walk over to the queue at the line printer awaiting the output of your program. Each output on green&#x2F;gray continuous linked A3 paper started with a full listing of your code as typed. If there were errors in your code this would be followed by a huge pile of full code repeats indicating were things went wrong. I still think the enormous stack of pages printed in those cases was mainly to shame the programmer as they had to stand there waiting for the relentless ongoing machine gun like soundings of the line printer anoucing your failiure to the chuckles head shakes of the others standing in line. However, if you were at one of the satelite programming rooms spread around the campusses, , now was the time to go home as your output print would be delivered by van in the following batch typically the next day when you would go and pick up your output from all of them lying on a set of tables, hoping yours was not one of the bigger stacks indicating an error had been found.