TITLE: William Cook on Industry and Academia
AUTHOR: Eugene Wallingford
DATE: October 27, 2009  9:47 PM
DESC: 
-----
BODY:
I really enjoyed reading the text of William Cook's
<A HREF="http://wcook.blogspot.com/2009/10/ecoop-2009-banquet-speech.html">
   banquet speech at ECOOP 2009</A>.
When I served as tutorials chair for
<A HREF="http://www.oopsla.org/2006/">
   OOPSLA 2006</A>,
Cook was program chair, and that gave me a chance
to meet him and learn a bit about his background.
He has an interesting career story to tell.  In
this talk, he tells us this story as a way to
compare and contrast computer science in academia
and in industry.  It's well worth a read.

As a doctoral student, I thought my career path
might look similar to Cook's.  I applied for
research positions in industry, with two of the
Big Six accounting firms and with an automobile
manufacturer, at the same time I applied for
academic positions.  In the end, after years of
leaning toward industry, I decided to accept a
faculty position.  As a result, my experience with
industrial CS research and development is limited
to summer positions and to interactions throughout
grad school.

Cook's talk needs no summary; you should read it
for yourself.  Here are a few points that stood
out to me as I read:

<BLOCKQUOTE><EM>
Venture capitalists talk about pain killers versus
vitamins.  A vitamin is a product that might make
you healthier over the long run, but it's hard to
tell.  Pain killers are products where the customer
screams "give it to me now" and asks what it costs
later.  Venture capitalists only want to fund pain
killers.
</EM></BLOCKQUOTE>

This is true not only of venture capitalists, but
of lots of people.  As a professor, I recognize
this in myself and in my students all of the time.
Cook points out that most software development tools
are vitamins.  So are many of the best development
practices.  We need to learn tools and practices
that will make us most productive and powerful in
the long run, but without short-term pain we may
not generate the resolve to do so.

<BLOCKQUOTE><EM>
We read all the standard references on OO for
business applications.  It didn't make sense to us.
We started investigating model-driven development
styles.  We created modeling languages for data,
user interfaces, security and workflow.  These four
aspects are the core of any enterprise application.
We created interpreters to run the languages, and
our interpreters did many powerful optimizations by
weaving together the different aspects.
</EM></BLOCKQUOTE>

To me, this part of the talk exemplifies best how
a computer scientist thinks differently than a
non-computer scientist, whether experienced in
software development or not.  Languages are tools
we create to help us solve problems, not merely
someone else's solutions we pluck off the shelf.
Language processors are tools we create to make
our languages come to life in solving instances
of actual problems.

<BLOCKQUOTE><EM>
The way I see it is that industry generally has
more problems than they do solutions, but academia
often has more solutions than problems.
</EM></BLOCKQUOTE>

Cook makes a great case for a bidirectional flow
between industry, with its challenging problems in
context, and academia, with its solutions built of
theory, abstraction, and design.  This transfer can
be mutually beneficial, but it is complicated by
context:

<BLOCKQUOTE><EM>
Industrial problems are often messy and tied to
specific technical situations or domains.  It is
not easy to translate these complex problems into
something that can be worked on in academia.  This
translation involves abstraction and selection.
</EM></BLOCKQUOTE>

The challenge is greatest when we then take
solutions to problems abstracted from real-world
details and selected for interestingness more than
business value and try to re-inject them into the
wild.  Too often, these solutions fail to take hold,
not because people in industry are "stupid or timid"
but because <EM>the solution doesn't solve their
problem</EM>.  It solves an ideal problem, not a
real one.  The translation process from research to
development requires a finishing step that people
in the research lab often have little interest in
doing and that people in the development studio have
little time to implement.  The result is a disconnect
that can sour the relationship unnecessarily.

Finally, the talk is full of pithy lines that I hope
to steal and use to good effect sometime soon.  Here
is my favorite:

<BLOCKQUOTE><EM>
Simplicity is not where things start.  ...  It is
where they end.
</EM></BLOCKQUOTE>

Computer scientists seek simplicity, whether in
academia or in industry.  Cook gives us some clues
in this talk about how people in these spheres can 
understand one another better and, perhaps, work
better together toward their common goal.
-----