Discussion Points/Questions/Topics for class

1. Question: What stuff that we're reading is obsolete and what stuff
is still very applicable?  For example, one reading mentioned a
program that took about a week to compile.  I can't imagine even
a poorly designed large program taking a week to compile on a 
modern day computer.

2. Topic for class: Writing code so that it is easily extensible.  

3. Question: What is a good rule of thumb for how many people
you could assign to a project of a given size before the diseconomies 
of scale really kick in?

Themes across multiple sources:

 - Look for bugs as you go; don't wait until you're almost done.  

 - Adding more people to a project is not always a good idea. 

 - The difficulty in debugging grows exponentially with the size of the 
program.

What I agree with:

 - It is much less time consuming to try to write neat and clean code 
the first time around than to write sloppy and then try to debug.  

What I disagree with:

 - Some of the stuff about optimization seems a bit out of date.  
Hardware is pretty fast these days and alot of compilers will optimize
things for you.  Same with some of the error checking stuff.  I can't 
remember which book I was reading from, but one of them mentioned 
something about keeping a copy of your code with a bunch of assert 
statements everywhere for debugging purposes.  I could see how it would
be useful for finding array out of bounds exceptions and things like 
that, but today, with modern things like Java, I don't think that that 
would be worthwhile.  

What seems intuitive:

- That finding bugs grows exponentially harder with the size of the 
program.  It makes sense because the number of things in memory grows
(very roughly) linearly with the size of the program, so the number of 
possible combinations of things in memory that could produce an error 
would grow exponentially.  

What seems counterintuitive:

- That productivity per programmer decreases so rapidly as the number of 
programmers assigned to a project increases.  I would think that, while 
there would be some interdependencies across the whole program, you 
would be able to divide a big program with millions of lines of code 
into big chunks that are reasonably independent, and then within those 
chunk you could further divide the work into parts and so on.  It just 
seems like in a program of that size, there would be good ways of 
dividing the work.  

What surprised me:

What surprised me was how quickly adding more people to a project could 
make the project actually take longer.  I can see how each person would 
add less as the project grows, but I would think that a person 
contributing something would at worst just not help the project at all.  
I suppose there is the time it takes the other programmers to train the 
new guy, but that seems negligible compared to the amount of time the 
guy would spend coding.