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

[Scott Condit]

Peter E.C. Dashwood wrote:

If components (whether ActiveX or Java Beans) are properly wrapped (and they
have to be, to BE ActiveX or Java Beans) there will be NO NEED to make any
change to them whatsoever when running under a new OS or in a new
environment.

Q: What OS environments do ActiveX controls run on?
A: Only Win32.

S

[Bent C Dalager]

In article <bg************ @ID-189137.news.uni-berlin.de>,
Scott Condit <so****@socode. com> wrote:

Q: What OS environments do ActiveX controls run on?
A: Only Win32.

A more interesting question is: will they run on Win64? And they
probably will.

Cheers
Bent D
--
Bent Dalager - bc*@pvv.org - http://www.pvv.org/~bcd
powered by emacs

[Harley]

"Roedy Green" <ro***@mindprod .com> wrote in message
news:ue******** *************** *********@4ax.c om...
| On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
| <Do*********@sy mpatico.ca> wrote or quoted :
|
| >Aren't you talking about marriage or something? About the *only* code I
| >know that is still running after 15 years use is in Cobol. I could say
the
| >same for 30 years.
|
| If the code is running unmodified in 20 years, most likely that code
| is so obscure nobody knows how to change it, so it locks a business
| rule into place, that really should be flexible.

There is no such thing as "so obscure nobody knows how to change it".
It may be a challenge to follow a process, but it's never impossible.
Running the process, and checking the output, gives you an idea of what is
going on in the module.
Even if the source code is long gone, the testing process can give you
enough information to construct a replacement.
You have two of the three: Input, Process, Output.

Original programs may go back 20 years or more, but for the most part
enhancements have been made. There may be programs that have run untouched
for 20 years, but they the exception, not the rule.
I think that program enhancement falls under the reuse umbrella.

| In real life I have seen people emulating code for hardware that has
| not existed for a decade mainly because they long ago lost the source
| code.

AND the process still satisfies a business need.

|
| Consider how many times that code will have to be read by maintenance
| programmers, even if not changed, over that 20 years. You want to go
| for something that is READABLE.

Agree.

|
| Java Gui code is not readable, but non-gui code is fairly good. It
| should be considerably better with Java 1.5.

I sometimes take monstrous code, copy it, and edit my copy to improve
readability, and get a handle on what's going on.

Reformatting the structure, and changing data names may help make the code a
bit more readable.
Since you're not modifying the actual source code, your changes don't have
to conform to language restrictions.

You can write unreadable code in any language.

[Donald Tees]

"Peter E.C. Dashwood" <da******@enter net.co.nz> wrote in message
news:3f******** @news.athenanew s.com...

"Donald Tees" <Do*********@sy mpatico.ca> wrote in message
news:mu******** **********@news 20.bellglobal.c om...

"Peter E.C. Dashwood" <da******@enter net.co.nz> wrote in message
news:3f******** @news.athenanew s.com...

> >

The source language is irrelevant in terms of code re-use. (It is OBJECT code that will be re-used...)

You should select a source language SUITABLE FOR THE JOB YOU WANT TO DO!!!
Then make sure that an OO or modular approach is adopted, wrap your
functions as components, and you can reuse them FOR EVER not just 15 years.

Pete.

Aren't you talking about marriage or something? About the *only* code I
know that is still running after 15 years use is in Cobol. I could say

the

same for 30 years.

There is no reason to believe that what has been true in the past will be
true in the future.

On the contrary, the indications are that the future which is emerging for
IT will be VERY DIFFERENT from the IT past...

Even in the last five years, the components I have used have evolved into different packaging, required updates for each OS, etc. etc.

Then your definition of "component" differs from mine.

If components (whether ActiveX or Java Beans) are properly wrapped (and

they have to be, to BE ActiveX or Java Beans) there will be NO NEED to make any
change to them whatsoever when running under a new OS or in a new
environment.

If you needed to change the functionality, that is a design issue which has nothing to do with the Language in use.

I have components running on the Web, under Windows, and (in one case) under Linux. They have never required any changes from the day they were released.
I believe that qualifies as a good definition of "re-use".

Pete.

So what you are telling me is that if I take my GL system(written in Cobol),
and properly wrap it in an OCX wrapper, then suddenly all the code becomes
perfect, and it will not need maintenance ever again?

Perhaps we should all do that, and then trade OCX's. It would be a lot
easier than maintaining the stuff.

Donald

[Donald Tees]

"Roedy Green" <ro***@mindprod .com> wrote in message
news:ue******** *************** *********@4ax.c om...

On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
<Do*********@sy mpatico.ca> wrote or quoted :

Aren't you talking about marriage or something? About the *only* code I
know that is still running after 15 years use is in Cobol. I could say thesame for 30 years.
If the code is running unmodified in 20 years, most likely that code
is so obscure nobody knows how to change it, so it locks a business
rule into place, that really should be flexible.

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.

Donald
In real life I have seen people emulating code for hardware that has
not existed for a decade mainly because they long ago lost the source
code.

Consider how many times that code will have to be read by maintenance
programmers, even if not changed, over that 20 years. You want to go
for something that is READABLE.

Java Gui code is not readable, but non-gui code is fairly good. It
should be considerably better with Java 1.5.

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

[Howard Brazee]

On 4-Aug-2003, "Peter E.C. Dashwood" <da******@enter net.co.nz> wrote:

There is no reason to believe that what has been true in the past will be
true in the future.

On the contrary, the indications are that the future which is emerging for
IT will be VERY DIFFERENT from the IT past...

True enough. But one thing will likely remain the same - our ability to
predict how the future will be different.

[Howard Brazee]

On 5-Aug-2003, qe*@pobox.com (Paul Hsieh) wrote:

COBOL and Pascal (the other groups you crossposted this message to)
will decrease in usage over time, not increase. There is absolutely
no new serious development being done in either language.

Absolutely? I infer that the new development I see and do in CoBOL is all
jocular.

[Harley]

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.

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.

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.

[lvirden]

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?
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 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.
--
<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/ >

[lvirden]

:The source language is irrelevant in terms of code re-use. (It is OBJECT
:code that will be re-used...)
:
:You should select a source language SUITABLE FOR THE JOB YOU WANT TO DO!!!

However, if the job being done is to develop a system which needs to continue
to be supported, and developed, for a long period of time, then the
language becomes at least a topic to be addressed.

One shouldn't _ignore_ the issue. One should consider it, build a business
case, then proceed.

If, for instance, one is deploying an application across a wide geographic
area, in a domain where applications need to run for long periods of time
with little down time, reliability issues, and little chance for replacements
(but possibilities for upgrades) etc., then one would hate to be saddled
with a language that in 5, 10, or 15 years few people will know. How many
developers can today develop, maintain, and debug in snobol, algol, rpg,
....
--
<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/ >