NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/4997

Text File | 1992-12-16 | 2.8 KB | 67 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!psinntp!sugar!claird
From: [e-mail] (Cameron Laird)
Subject: Commercial realities of porting (was: Request for reuse tool info)
Organization: NeoSoft Communications Services -- [phone]
Date: Tue, 15 Dec 1992 18:37:44 GMT
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 56

In article <[e-mail]> [e-mail] (Scott Mcgregor) writes:
>In article <[e-mail]> [e-mail] (Phil Julian) writes:
>
>>From this scenario, reuse is bad for resumes.  What do other
>>programmers or employers value more -- reusing old code or writing
>>original code?  The problem may be our own attitudes and the attitudes
>>of the marketplace.  Reuse is not valued as an intrinsic skill.  I
I so value it.
            .
            .
            .
>This is, for example, part of SAS Institute's competative advantage,
>that they have designed their product in such a way that much of it
>can be mounted on a new computer system with just a re-compile, which
>makes adding a new system to the support list relatively more
>inexpensive, faster and reliable than a ground up port.
Change of subject:  is that the best way to tell the
story?  I've worked on a lot of porting during the
last couple of decades.  I know that it is possible
and desirable for the narrow-sense source code--C
and FORTRAN implementations, associated headers,
that sort of thing--to move very, very cleanly from
one environment to another.  HOWEVER, in my experi-
ence, the cost of the port is overwhelmingly
dominated not by such programming language consider-
ations, but by
1.  maintenance on a new platform;
2.  quality assurance on a new platform;
3.  documentation for a new platform; and
4.  customer support for a new platform.
The first and last of these are the killers.  More
than once, I've spent weeks on the telephone, ar-
ranging for suitable hardware, then moved several
hundreds of thousands of lines of source and gen-
erated a product from them in under twenty-four
hours.  Even then, a perfectly functional applica-
tion can be better off sitting on the shelf, because
maintaining the hardware to support it might cost
more than any conceivable revenues.

Time will dilute these conclusions.  As hardware
become relatively cheaper and more standardized,
it will be more and more realistic to have a
machine room filled with "one of each".  For now,
though, my best judgment continues to be that
people overestimate the costs of porting source,
and underestimate the costs of supporting multiple
platforms.
            .
            .
            .
--

Cameron Laird
[e-mail] ([e-mail])    [phone]
[e-mail] ([e-mail])      [phone]