TITLE: "Yes, We Do That"
AUTHOR: Eugene Wallingford
DATE: September 10, 2008  2:59 PM
DESC: 
-----
BODY:
When I was in grad school, my advisor sent me to a series
of swank conferences on expert systems in business, finance,
and accounting.  Among the things these conferences did
for me was to give a chance to stay at Ritz Carlton hotels.
This Midwestern boy had never been treated so well.

At the 1990 conference, I heard a talk by Gary Ribar from
KPMG Peat Marwick, one of the Big Six accounting consulting
firms of the time.  Ribar described LoanProbe, a program
that evaluated the collectibility of commercial loans.
LoanProbe was a rule-based system organized in a peculiar
way, with its 9000 rules separated into thirty-three separate
"knowledge bases".  It was a significant application that
interacted with sixty external programs and two large data
bases.  Peat Marwick took LoanProbe a step further and used
its organizational technique to build a knowledge acquisition
program that enabled non-programmers to create systems with
a similar structure.

I was so excited.  I recognized this technique as what we
in our lab called
<A HREF="http://www.cs.uni.edu/~wallingf/patterns/structured-matcher.pdf">
  structured matching</A>,
a remarkably common and versatile pattern in knowledge-based
systems.  LoanProbe looked to me like the largest documented
application of structured matching, which I was working on
as a part of my research.  Naturally, I wanted to make a
connection to this work and share experiences with the
speaker.

After the talk, I waited in line to speak with him.  When
my turn came, I gushed that their generic architecture was
very cool and that "we do something just like that in our
lab!".  I expected camaraderie, but all I received back
was an icy stare, a curt response, and an end to the
conversation.

I didn't understand.  Call me naive.  For a while, I
wondered if Mr. Ribar was simply an unfriendly guy.  Then
I realized that he probably took my comment not as a
compliment -- We do that, too! -- but as a claim that
the work he described was less valuable because it was
not novel.  I realized that I had violated one of the
basic courtesies of research by telling him that his work
was known already.

These days, I think fondly of Ribar, that talk, and that
conference.  He was behaving perfectly reasonably, given
the culture in which he worked.  Novelty is prized.

A few years after that conference, I came across
<A HREF="http://www.hillside.net/conferences/plop.htm">
   PLoP</A>
and the software patterns community.  This group of people
valued discovering, documenting, and sharing common
solutions, the patterns that make our software and our
programming lives better.  Structured Matcher did that,
and it appeared in programs from all sorts of domain.

Jeff Patton has described this feature of the patterns
community nicely in his
<A HREF="http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html">
   article on emerging best practices</A>
in user experience:

<BLOCKQUOTE><EM>
If you tell someone a great idea, and they say "Yes, we
do something like that too!", <STRONG>that's</STRONG>
a pattern.
</EM></BLOCKQUOTE>

Documenting and sharing old, proven solutions that
expert practitioners use may not get you a publication
in the best research journal (though it might, if you
are persistent and fortunate), but it will make the
world better for programmers and software users.  That
is valuable, too.
-----