TITLE: A Semester's Worth of Technical Debt
AUTHOR: Eugene Wallingford
DATE: December 12, 2019  3:20 PM
DESC: 
-----
BODY:
 I've been thinking a lot about technical debt this week.  My student
 teams are in Week 13 of their compiler project and getting ready to
 submit their final systems.  They've been living with their code
 long enough now to appreciate
<A HREF="http://wiki.c2.com/?WardExplainsDebtMetaphor">
   Ward Cunningham's original idea</A>
 of technical debt: the distance between their understanding and the
 understanding embodied in their systems.

<BLOCKQUOTE><EM>
  ... it was important to me that we accumulate the learnings we did
 about the application over time by modifying the program to look as
 if we had known what we were doing all along and to look as if it
 had been easy to do in Smalltalk.
</EM></BLOCKQUOTE>

 Actually, I think they are experiencing two gulfs: one relates to
 their understanding of the domain, compilers, and the other to
 their understanding of how to build software.  Obviously, they are
 just learning about compilers and how to build one, so their content
 knowledge has grown rapidly while they've been programming.  But
 they are also novice software engineers.  They are really just
 learning how to build a big software system of any kind.  Their
 knowledge of project management, communication, and their tools has
 also grown rapidly in parallel with building their system.

 They have learned a lot about both content and process this semester.
 Several of them wish they had time to refactor -- to pay back the
 debt they accumulated honestly along the way -- but university
 courses have to end.  Perhaps one or two of them will do what one or
 two students in most past semesters have done: put some of their own
 time into their compilers after the course ends, to see if they can
 modify the program to look as if they had known what they were doing
 all along, and to look as if it had been easy to do in Java or Python.
 There's a lot of satisfaction to be found at the end of that path,
 if they have the time and curiosity to take it.

 One team leader tried to bridge the gulf in real time over the last
 couple of weeks:  He was so unhappy with the gap between his team's
 code and their understanding that he did a complete rewrite of the
 first five stages of their compiler.  This team learned what every
 team learns about rewrites and large-scale refactoring: they spend
 time that could otherwise have been spent on new development.  In a
 time-boxed course, this doesn't always work well.  That said, though,
 they will likely end up with a solid compiler -- as well as a lot of
 new knowledge about how to build software.

 Being a prof is fun in many ways.  One is getting to watch students
 learn how to build something while they are building it, and coming
 out on the other side with new code and new understanding.
-----