First Lecture:
(with input from Mark Ursino, December 2008)

1. Type of course

You learn about software development techniques
(incremental software development, data binding technology, 
structure-shy programming, testing approaches,
Law of Demeter, etc.)
and you practice them by creating an organism
that can survive in an artificial world created
by rules.
It is essential  that you
apply material from prerequisite courses:

You *must* be able to 

- Program in Java (from Object-Oriented Design;
   we will use DemeterF to review Java
   and use it in a new way using structure-shy programming)

- Derive probabilities (from Discrete Structures)
- Minimize and maximize polynomials and rational functions (from Calculus)
- Understand context-free grammars, from Theory of Computation.
- Understand NP, NP-complete and P, etc. from Theory
   of Computation.

2. Teaching style (Immersion)

You will learn about software development by doing it!!

Why: experience and failure is often a good teacher.

How: there will be updates of the requirements
from time to time.
And you need to update your organism quickly for the
new requirements.

Quote:
You might not
necessarily teach something specific, but students will learn it on
their own (often learning comes from failure). For example, if I could
start all over, the first thing I would do would be to create a test
suite to test my future functionality.

Side note: the whole "immersion" thing is similar to when people learn
a foreign language by going to that country. It forces them to learn
the language since that's all there is around them and to survive in
the new environment, they need to adapt to it and learn it.

3. Fair teams

Fill out questionnaire. Good balance of skills. If the class
has an odd number of students there will be one team of 3.

4. Environment Help

Quote:

Also, we found it very useful to keep our player code as well as a
copy of Eclipse on a USB hard drive. Since Eclipse just needs to be
unzipped into a folder, it's easy to carry on a portable drive with
player code. This allows students to work on their project in various
places. We also did this with our subprojects since we often worked on
those in the 102 lab. This code mobility can also benefit class-time
code reviews with ease-of-access to code.

5. Privacy of your code, learning from others, code reviews

Starting in the week after the third competition, all teams must make
their code from two weeks prior available to all:

Player dev week 1
 - Competition 1

Player dev week 2
 - Competition 2

Player dev week 3
 - All must make their week 1 code available
 - Competition 3

Player dev week 4
 - All must make their week 2 code available
 - Competition 4

 ...

Player dev week n
 - All must make their week (n-2) code available
 - Competition n

Doing this can allow teams to learn from others but not gain a
significant amount of new knowledge that will rip-off other players.
Doing this also means you can have public code reviews only on old
code that has been made public.

5. Two markets

Markets of Derivatives
Markets of Software Components produced by other teams.