TITLE: Slipping Schedules and Changing Scope in the Compiler Course
AUTHOR: Eugene Wallingford
DATE: April 17, 2009  8:20 PM
DESC: 
-----
BODY:
We have fallen behind in my compilers course.  You may
recall that before the semester I
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-01.html#e2009-01-07T18_18_57.htm">
   contemplated some changes</A>
in the course, including letting letting the students
design their own language.  My group of six chose that
route, and as a part of that choice decided to work as
a team of six, rather than in pairs or threes.  This
was the first time for me to have either of these
situations in class, and I was curious to see how it
would turn out.

Designing a language is tough, and even having lots of
examples to work from, both languages and documents
describing languages, is not enough to make it easy.
We took a little longer than I expected.  Actually,
the team met its design deadline (with no time to
spare, but...), but then followed a period of thinking
more about the language.  We both needed to come to a
better understanding of the implications of some of
their design decisions.  Over time they changed their
definition, sometimes refining and sometimes simply
making the language different.  This slowed the process
of starting to implement the language and caused a few
false starts in the scanner and parser.

Such bumps are a natural part of taking on the tougher
problem of creating the language, so I don't mind that
we are behind.  I have learned a few things to do
differently the next time a compiler class chooses
this route.  Working as a team of six increases the
communication overhead they face, so I need to do a
better job preparing them for the management component
of such a large development project.  It's hard for a
team to manage itself, either through specific roles
that include a nominal team leader or through town-hall
style democracy.  As the instructor, I need to watch
for moments when the team needs me to take the rudder
and guide things a bit more closely.  Still, I think
that this has been a valuable experience for the students.
When they get out into industry, they will see successes
and failures of the sort they've created for themselves
this semester.

Still, things have gone reasonably well.  It's almost
inevitable that occasional disagreements about technical
detail or team management will arise.  People are people,
and we are all hard to work with sometimes.  But I've
been happy with the attitude that all have brought to the
project.  I think all have shown a reasonable degree of
commitment to the project, too, though they may not
realize yet just what sort of commitment getting a big
project like this done can require.

I have resisted the urge to tell (or re-tell?) the story
of my senior team project: a self-selected team of good
programmers and students who nonetheless found ways to
fall way behind their development schedule.  We had
no way to change the scope of the system, struggled
mightily in the last weeks of the two-term project,
and watched our system crash on the day of the acceptance
test.  The average number of hours I spent on this project
during its second term?  62 hours.  And that was while
taking another CS course, two accounting courses, and
a numerical analysis course -- the final exam for which
I have literally no recollection of at all, because by
that time I was functioning on nearly zero sleep for
days on end.  This story probably makes me sound crazy
-- not committed, but in need of <EM>being</EM> committed.
Sometimes, that's what a project takes.

On the technical side, I will do more next time to
accelerate our understanding of the new language and
our fixing of the definition.  One approach I'm
considering is early homework assignments writing programs
in the new language, even before we have a scanner or
parser.  This causes us all to get concrete sooner.
Maybe I will offer extra-credit points to students who
catch errors in the spec or in others students' programs.
I'll definitely give extra-credit for catching errors in
my programs.  That's always fun, and I make a perfect
foil for the class.  I am sure both to make mistakes and
to find holes in their design or their understanding of
it.

But what about this semester?  We are behind, with three
weeks to D-Day.  What is the best solution?

The first thing to recognize is that sometimes this sort
of thing happens.  I do not have the authority to
implement a death march, short of becoming an ineffective
martinet.  While I could try telling students that they
will receive incompletes until the project is finished,
I don't really have the authority to push the deadline of
the project beyond the end of our semester.

The better option is one not made available to my project
team in school, but which we in the software world now
recognize as an essential option: reduce the scope of
the project.  The team and I discussed this early in
the week.  We can't do much to make the language smaller,
because it is already rather sparse in data types,
primitive operators, and control structure.  The one
thing we could drop is higher-order procedures, but I
was so please when they included this feature  that I
would feel bad watching it drop out now.  But that would
not really solve our problem.  I am not sure they could
complete a compiler for the rest of the language in
time anyway.

We decided instead to change the target language from
JVM bytecodes to Java itself.  This simplifies what
remains for them quite a bit, but not so much that it
makes the job easy.  The big things we lose are
designing and implementing a low-level run-time system
and emitting machine-level code.  The flip side is that
we decided to retain the language's support for
higher-order procedures, which is not trivial to
implement in generated Java code.  They'll still get
to think about and implement closures, perhaps using
anonymous inner classes to implement function arguments
and results.

This results in a different challenge, and a change in
the experience the students will have.  The object
lesson  is a good one.  We have made a trade-off, and
that is the nature of life for programmers.  Change
happens, and things don't always proceed according to
plan.  So we adapt and do the best we can.  We might
even spend 60 hours one week working on our project!

For me, the biggest effect of the change is on our
last two and a half weeks of lecture.  Given where we
are and what they will be doing, what do they most
need to learn?  What ideas and techniques should they
see even if they won't use them in their compilers?
I get to have some fun right up to the end, too.
-----