TITLE: A Broken Record?
AUTHOR: Eugene Wallingford
DATE: January 29, 2008  4:20 PM
DESC: 
-----
BODY:
Last night I attended a meeting with several CS colleagues,
colleagues from Physics and Industrial Technology,
representatives from the local company
<A HREF="http://www.distek.com/">
   DISTek Integration</A>,
and representatives from
<A HREF="http://www.ni.com/">
   National Instruments</A>,
which produces the programming environment
<A HREF="http://www.ni.com/labview/">
   LabVIEW</A>.
Part of the meeting was about LabVIEW and how students and
faculty at my school use it.  Our CS department does not
use it at all, which is typical; the physicists and
technologists use it to create apps for data acquisition
and machine control.

Most of the meeting was much more interesting than tool
talk and sales pitch, because it was about how to excite
more kids and university students about IT careers and
programming, and about how LabVIEW users work.  Most of
the folks who program in LabVIEW at DISTek are test
engineers, not trained software developers.  But the
programming environment makes it possible for them to
build surprisingly complex applications.  As they grow
their apps, and attack bigger problems because they can,
the programs become unwieldy and become increasingly
difficult to maintain and extend.

It turns out that program design matters.  It turns out
that software architecture matters.  But these programmers
aren't trained in the writing software, and so they do
much of their work with little or no understanding of
how to structure their code, or refactor it into something
more manageable.

These folks are engineers, not scientists, but I felt
a deep sense of <EM>deja vu</EM>.  Our conversations
sounded a lot like what we discussed
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-11.html#e2007-11-20T13_28_03.htm">
   with physicists</A>
at the SECANT workshop to which I keep referring.

I think we have a great opportunity to work with the folks
at DISTek to help their domain-specific programmers learn
the software development skills they need to become more
effective programmers.  Working with them will require us
to think about how to teach a focused software development
curriculum for non-programmers.  I think that this will be
work worth doing as we encounter more and more folks, in
more and diverse domains, who need that sort of software
development education -- not a major or maybe even minor
in CS -- in order to do what they do.
-----