From: jeh@acpub.duke.edu (JUSTIN HARLOW)
Newsgroups: comp.lsi.cad
Subject: Re: Why universities shouldn't write IC CAD tools
Date: 16 Oct 92 11:39:03 GMT
Organization: Duke University; Durham, N.C.

As a program manager at Semiconductor Research Corporation (SRC), I have
been following this thread with considerable interest. SRC funds a large
number of universities in design and CAD (among other things) research,
and we are frequently taken to task by member companies for the, shall we
say, "uneven" quality of the resulting software.

We have tried for years to get a handle on the problem of how you
balance the universities' need to produce PhDs and ideas, against the
needs of the companies who provide the funding to receive useful results
from their investment. Here are a few things we have learned:

1. A university has graduating students as its primary "product". In
most cases, any extra effort spent in attempting to "harden" software
that results from research is effort not spent on their primary mission.
The old cliches about "publish or perish" are missing the point; you get
a PhD by coming up with new ideas, not by writing software. The software
is normally a proof of concept vehicle, and nothing more.

2. Hardening software is an expensive business. As many people pointed
out, the only way to do this is usually to start from scratch, using the
kernel of novel algorithms produced by the university. SRC has taken
bids from quasi-public institutions who proposed to do this process for
several very popular university software packages, but the cost was
prohibitive. The very people who complain about the quality of
university code are unwilling, in the final analysis, to pay the true
cost of elevating the quality of the code.

3. Industrial sponsors of university CAD programs can, and frequently
do, produce hardened versions of university code that are customized to
their needs. This is often very successful (someone cited AT&T and Larry
Nagel), but is quite expensive as well. The main difference from the
third-party hardening process is that the inhouse cost of the process is
usually well-buried in a corporate support group, so it seems less
expensive. If you were to do a serious business analysis, though, you
would almost always find that the inhouse option is MUCH more costly than
any third party approach (flames to /dev/null, please).

4. CAD companies probably deserve most of the flak they receive. Most
of them don't like to admit it, but their real business is code
hardening, user environments, and customer support. Many of their
customers say that they do a poor job of all three... The fact remains
that nearly every commercial CAD tool you can name has its origins in
the university system; that is where the ideas and algorithms
originate. Those companies are reasonably good at bulletproofing and
evolving the software, but none of them are renowned for their
innovation. Ask them how many of their people are experts in detail
routing or numerical analysis, and then ask how many do X-Windows
interfaces, manuals, phone support, regression testing, etc. They won't
answer you, of course, but the ratio is going to be about 1 to 100.

5. Some universities (and most of you know who they are) do a MUCH
better job of producing code than others. SRC has been trying to
understand this phenomenon for some time now, since after all, built-in
quality is nearly always cheaper than tested-in or bolted-on quality. we
find that the schools producing consistently superior code have a
software engineering culture that takes on a life of its own. No student
can be a lonely hacker, because the peer network provides subtle
pressures to re-use good code and contribute to the pool. Informal peer
review, competition with other students, professors with missionary zeal
about software engineering, and many other factors exist in these
places, with the result that the tape they send you is as good as a lot
of commercial code.

6. Many companies find that they get the best of all worlds by getting
involved personally with the students and faculty who are developing
code they want. Sending an industrial visitor to the university,
sponsoring sabbaticals, providing industrial-grade test cases, hiring
students for the summer,.... all of these things work wonders.
Conversely, just waiting until the work is complete and asking for the
tape is rarely very successful, as pointed out by many readers of this
newsgroup.

Sorry about the length of this ramble. My point is that 

(a) Universities are not software factories
(b) Software factories are expensive and imperfect
(c) Some universities know how to build quality into research software
    better than others.
(d) Potential users of university code get better results if they
    involve themselves in the development of the code.


Justin E. Harlow III
SRC Program Manager
harlow@src.org
919/541-9400



-- 
-------------------------------------------------------------------------
Justin E. Harlow III		Office:	harlow@src.org
Vox:	919/541-9464		School: jharlow@egr.duke.edu
Fax: 	919/541-9450		Snail:	SRC, PO Box 12053, RTP, NC 27709
Xref: sparky comp.lsi.cad:1020 comp.lsi:633