TITLE: Thinking about Software Development and My Compilers Course
AUTHOR: Eugene Wallingford
DATE: August 26, 2010  9:39 PM
DESC: 
-----
BODY:
Our semester is underway.  I've had the pleasure of
meeting my compilers course twice and am looking
forward to diving into some code next week.  As I
read these days, I am keenly watching for things I
can bring into our project, both the content of
defining and interpreting language and the process
of student teams writing a compiler.  Of course, I
end up imposing this viewpoint on whatever I read!
Lately, I've been seeing a lot that makes me think
about the development process for the semester.

Greg Wilson recently posted three rules for
<A HREF="http://third-bit.com/blog/archives/4003.html">
   for supervising student programming projects</A>.
I think these rules are just as useful for the
students as they work on their projects.  In a
big project course, students need to think
about time, technology, and team interaction
realistically in a way they.  I especially like
the rule, "Steady beats smart every time".  It
gives students hope when things get tough, even
if they are smart.  More importantly, it encourages
them to <B>start</B> and to keep moving.  That's
the best way to make progress, no matter smart
you are.  (I
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-02.html#e2009-02-25T18_45_53.htm">
   gave similar advice</A>
during my last offering of compilers.)  My most
successful project teams in both the compilers
course and in our Intelligent Systems course
were the once who humbly kept working, one shovel
of dirt at a time.

I'd love to help my compiler students develop in
an agile way, to the extent they are comfortable.
Of course, we don't have time for a
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-06.html#e2010-06-11T19_31_32.htm">
   full agile development course</A>
while learning the intricacies of language
translation.  In most of our project courses,
we teach some project management along side the
course content.  This means devoting a relatively
small amount of time to team and management
functions.  So I will have to stick to the
essential core of agile: <B>short iterations</B>
plus <B>continuous feedback</B>.  As
<A HREF="http://incontextdesign.com/blog/essential-agile/">
   Hugh Beyer writes</A>:

<BLOCKQUOTE><EM>
Everything else is there to make that core work
better, faster, or in a more organized way.  Throw
away everything else if you must but don't trade
off this core.
</EM></BLOCKQUOTE>

For the last couple of weeks, I have been thinking
about ways to decompose the traditional stages of
the compiler project (scanning, parsing, semantic
analysis, and code generation) into shorter
iterations.  We can certainly implement the parser
in two steps, first writing code to recognize legal
programs and then adding code to produce abstract
syntax.  The students in my most recent offering
of the compilers course also suggested splitting
the code generation phase of the project into two
parts, one for implementing the run-time system
and one for producing target code.  I like this
idea, but we will have to come up with ways to
test the separate pieces and get feedback from
the earlier piece of our code.

Another way we can increase feedback is to do more
in-class code reviews of the students' compilers
as they write them.  A student from the same
previous course offering wrote to me only yesterday,
in response to my article on
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-08.html#e2010-08-13T20_42_23.htm">
   learning from projects in industry</A>,
suggesting that reviews of student code would have
enhanced his project courses.  Too often professors
show students only their own code, which has been
designed and implemented to be clean and easy to
understand.  A lot of the most important learning
happens in working at the rough edges, encountering
problems that make things messy and solving them.
Other students' code has to confront and solve the
same problems, and reading that code and sharing
experiences is a great way to learn.

I'm a big fan of this idea, of course, and have
taught several of my courses using a studio style
in the past.  Now I just need to find a way to
bring more of that style into my compilers course.
-----