Future reuse of code

[James Cameron]

Hi I'm developing a program and the client is worried about future
reuse of the code. Say 5, 10, 15 years down the road. This will be a
major factor in selecting the development language. Any comments on
past experience, research articles, comments on the matter would be
much appreciated. I suspect something like C would be the best based
on comments I received from the VB news group.

Thanks for the help in advance

James Cameron

[lvirden]

According to Donald Tees <Do*********@sy mpatico.ca>:
: About the *only* code I
:know that is still running after 15 years use is in Cobol.

15 years isn't that long guys (1988!) - where I work , I don't know if there
_is_ any cobol. But they have C, IBM assembler, PL/1, and code in
a variety of other languages that has been running that long.

--
<URL: http://wiki.tcl.tk/ > <URL: http://www.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv*****@ yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >

[Mark Gordon]

On Mon, 04 Aug 2003 14:28:23 GMT
"jce" <de*********@ho tmail.com> wrote:

<snip>

You don't say what the application is which makes the response hard.
Some language are better for some things than others ;-)
Definitely. After all, one option to keep code reusable for 15 years is
to keep the HW and tools required to build & use it for 15 years.

<snip>
3. Does anyone really look to an application to last this long?
Yes. I know of SW written pre 1980 that was scheduled for further work
some time in 2000. This is code embedded in an avionics system which is
expected to be flying for another 15 years.

<snip>
4. The MOST important question is ........does it matter if I can
reuse it in 5 years if I cannot get it out of the door quickly now? No
point architecting a 15 year plan if it takes 5 years to execute and
you need it in 3 months. I didn't get that priority from your
original note.

If you are on your own then I only have one comment:
Narrow choices down to what you are comfortable with then add those
languages you are confident of handling. You have to deliver the
quality product NOW and not 15 years from now.
It might need to be delivered in 2 (or more) years time.
Here's the kicker:
Imagine......Su n goes belly up in 2006....Microso ft antes up with a
few billion to buy the Java licensing rights....woo hooo.....We'll all
try desperately to port to Inga's free open source virtual software
layer Ingot that runs on EyeBeeEmux to remove Microsoft
dependencies... .(remember they once thought the earth was flat and
that Senators were for the people). In 2015 we no longer run
processors as we know them. Electrons have been isolated on switches
that are built on self managed bio matter developed in the Democratic
People's China by po'd shepherds who refuse to divulge their methods
to the Communist States of America.

None of which is necessarily a problem. An acceptable solution might
involve keeping a stockpile of the HW to develop and run the
application. Of course, that might not be the case.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

[Mark Gordon]

On Mon, 04 Aug 2003 22:00:43 GMT
"Harley" <de************ *****@worldnet. att.net> wrote:

"jce" <de*********@ho tmail.com> wrote in message
news:ur******** ***********@twi ster.tampabay.r r.com...
| "Harley" <de************ *****@worldnet. att.net> wrote in message
| news:7q******** *************@b gtnsc05-news.ops.worldn et.att.net...
| >
| > "Malcolm" <ma*****@55bank .freeserve.co.u k> wrote in message
| > news:bg******** **@news8.svr.po l.co.uk...
| > |
| > | "James Cameron" <ja***********@ bindereng.com.a u> wrote in
| > | message
| > COBOL ain't dead yet.
| > It has a history, and some code that surpasses the 15 year
| > reusability requirement.
|
| If this was a requirement 15 years ago then it surpassed that
| requirement.
|
| I don't think this requirement is effective retroactively.

No, but there are languages that should have similary stories.
C++, and VB have been around for more than 5 years, so they have a
history. C has a longer history.

Isn't VB platform dependent?
Yes it is, it also has a history of changing.
| Question isn't what code has been reusable for 15 years....but what
| WILL
be
| reusable IN 15 years.

Any language that has a large customer base that would holler like
hell if it were abandoned, will be around for at least 15 years.
So Z80 assembler will be around for another 15 year. Actually, I know of
one product which has 15 years of support already signed up where the
software is a mix of Z80 assembler, PLM and an obsolete Pascal variant.
| COBOL has had a resurgence recently - question is whether it will
| hold up for 15 more years....Probab ly will....but you have to hope
| that the compilers/$$$ keep up or you'll just have something that
| works and isn't bleeding edge (what's wrong with that?).
|

Have you seen any evidence that the compilers have become stagnant?

Yes, and I know of one VAX that continues to run VMS4.x so that people
can continue to use the tools. Some time in the next 15 years my old
employer may have to port the code, but they will have problems with
availability of various chips as well so the hardware may need
redesigning as well.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

[Alistair Maclean]

In message <Pf************ ********@gigane ws.com>, JerryMouse
<no****@bisusa. com> writes

Huh? Dogs won't bark in North Carolina? The speed of light becomes less? The
world DEPENDS on things remaining - mostly - the same.

But the speed of light varies with the medium through which it travels.

--
Alistair Maclean

[jce]

"Mark Gordon" <sp******@fla sh-gordon.me.uk> wrote in message
news:2003080519 2555.6f69e3e5.s p******@flash-gordon.me.uk...

On Mon, 04 Aug 2003 14:28:23 GMT
"jce" <de*********@ho tmail.com> wrote:

3. Does anyone really look to an application to last this long?

<snip> Yes. I know of SW written pre 1980 that was scheduled for further work
some time in 2000. This is code embedded in an avionics system which is
expected to be flying for another 15 years. <snip>

I guess it was a shortsighted question. I guess I missed an entire genre of
software development.
With communication links, nuclear reactors, and even Hubble it would be
ridiculous to assume that the application is "short" lived. I am sure there
are many areas primarily looking at safety or stability (the IRS for example
I am sure wants their multi million dollar rewrites to last through some
more tax cuts and tax hikes).
Your comment made me think about my car electronics system. I'm cheap and
hope it will still be running in a few more years !
I'm of the...'they've got coffee that's instantaneous.. ..Good Technology'
generation :-)

<snip> None of which is necessarily a problem. An acceptable solution might
involve keeping a stockpile of the HW to develop and run the
application. Of course, that might not be the case.

<snip>
I guess that there are those companies reading 30 year old tapes for
customers so the hardware will always be there - but this also shows that
some people should have stockpiled their own hardware. Never seen a room
full of Apple 200 or 286's but it's certainly an angle that I hadn't thought
of. I guess at the end of the day there are many ways to skin a cat
including hardware solution.

Thanks for making me look at a slightly bigger picture.

JCE

[John C. Bollinger]

lv*****@yahoo.c om wrote:

According to Thomas Gagné <tg****@wide-open-west.com>:
:That's an interesting criterion. How reusable will the code be 15 years from
:now? Why not consider what makes code from 15 years ago reusable?

That's a great question - what are some libraries which were written
15 years ago still in use?
BLAS. The earliest recorded literature reference to BLAS is from 1979,
which makes it 24 years old this year. Based on that single data point,
then, the criterion must be that the library is written in Fortran. :-)
First, what is the criteria we are going to use - the code was written
15 years (or more) ago and never touched? Written 15 years ago and
continues to be maintained for portability? Written 15 years ago and
has undergone rewrites over time?
There's probably code in the first category on frozen systems - systems
where the only things being written are new reports, etc. but no new
applications written.
I'm not sure whether that should count, because the question is about
reuse, not longtime continuing use. We could argue about exactly what
we mean by "reuse".
I'm trying to think what open source projects might fall into this category
- what about pbmplus ? The official release was
http://www.acme.com/software/pbmplus...dec1991.tar.gz
so that software is 12 years ago. I suspect that people still use that
distribution.

We have a software suite currently use in our lab whose original version
dates back to the late 1950s. That makes it about 45 years old,
although it has seen quite a bit of maintenance over the years and
probably not much of the original code remains. It is written in
Fortran. The version I first worked on was pretty much gobbledygook --
working gobbledygook, mind -- that had been, at that time, maintained
for over thirty years and gone through at least three ports to new
systems. The deciding factor there was not accessibility of the code in
any sense, nor any secret or arcane technology. It was just that the
software was at least as useful as any alternative, likely aided by the
fact that the field is sufficiently specialized that the were only a few
alternatives.

Perhaps that kind of story can't happen any more.
John Bollinger
jo******@indian a.edu

[Roedy Green]

On 5 Aug 2003 16:54:00 GMT, lv*****@yahoo.c om wrote or quoted :

That's a great question - what are some libraries which were written
15 years ago still in use?

Some code like a math library the handle matrices need not change. It
has no user interface. The more a piece of software interacts with the
user and the OS, the more tweaking it will need just to keep it alive.

The more self-contained a piece of code is the safer it is. Otherwise
it has to change to match changes in any pieces it depends on. If one
of those pieces fails, a substitute must be found or created.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Peter E.C. Dashwood]

"Harley" <de************ *****@worldnet. att.net> wrote in message
news:OS******** *************@b gtnsc04-news.ops.worldn et.att.net...

Snipped much of post.

"Marco van de Voort" <ma****@toad.st ack.nl> wrote in message
news:slrnbivdbd .rak.ma****@toa d.stack.nl...
|
| There only has to come some major new fashionable paradigm that promises
| managers to shave off 1 percent of development cost, and the total
direction
| and focus of the programming community can change.
This is a very astute and accurate observation. However, I tend to agree
with Dennis' position below, that the whole business of coding will become
automated, and SOURCE code re-use is therefore irrelevant.

What I THINK will happen is that we will abandon coding altogether.
We will have system modeling tools that generate the program coding for us. Once the model is developed, the system could be generated for a variety of environments. You want a Windows version, no problem. You want a Unix
version, no problem. You want a mainframe version, no problem.
Yes, I agree strongly with this. I believe that by INTERACTION and ITERATION
with a Workshop of Users and IT people, the system will write itself. We can
ALMOST do this today, and I have managed projects where all the
functionality was derived from Joint Development Workshops, code was cut,
then the process iterated. It is a logical progression to have the code
generated instantly by a smart system. The best thing about this approach is
not the technology, but the fact that the Users get exactly what they
need/want right NOW, not what they needed/wanted six months ago when the
"Requiremen ts Gathering" phase was signed off...

The whole debate about "future re-use of code", insofar as it applies to
SOURCE code, is irrelevant.

Pete.

The only tricky thing will be the reverse engineering of existing systems
into the model.
I've seen this done, but the reverse engineered model didn't address the
system from a business perspective.

[Roedy Green]

On Tue, 5 Aug 2003 08:04:57 -0400, "Donald Tees"
<Do*********@sy mpatico.ca> wrote or quoted :

That simply is not true. The general ledger rules have not changed an ioto.
What has changed is operating system interfaces, and most of those have been
cosmetic ... screen I/O and formating of reports. The rules of accounting
are identical, the account number scheme is identical, etc. etc. Being able
to re-use has a lot more to do with breaking the rules of bussness out from
the fluff than it does about technology.

When I lived on Quadra Island the guy down the road made a living
writing custom Accpac modifications. This was done in a sort of
assembler for a very DOS-like model. There is a ton of this stuff
running Canadian businesses. Very few people understand it anymore.

Companies have paid high amounts to have these mods done, and they are
not portable. The whole scheme is frozen circa 1985.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Roedy Green]

On Tue, 5 Aug 2003 07:50:03 -0500, "JerryMouse " <no****@bisusa. com>
wrote or quoted :

That's a start with a false assumption. The 'business rules' of a general
ledger haven't changed since a mad monk invented them in the 1500's. The
basic rules of inventory control haven't changed since the start of an
agrarian society (you've got some, you take some away, you add some to the
pile).

I am using code for NEW applications I wrote back in 1979, so I have
no compunctions about using code just because it is old. What you want
though is for the code to be understandable and changeable IF YOU
WANTED TO. You should not be using code just because nobody knows how
to change it.

In the simplest case, somebody asks that a program collect some
information, then gradually you find the game is not worth the candle.
So you might as well remove that code, rather than forcing people to
make up data to keep the program happy.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.