Future reuse of code

[Howard Brazee]

| NOTHING will run 10 years from now!

You might want to qualify this by language.
(NOTHING written in ? will run 10 years from now!)
Be careful, there are people out there with 10 year old software that is
still running.

Correct - most of the software I work with is older than that.

But if we are talking about "reuseable", I wonder what we should be looking for.
Do we worry about plugging in the algorithm used to determine depreciation so
we don't have to analyze it again?

Coding it is simple in any language, so I am guessing we are talking about
keeping analysis and testing down. Except we will still need to analyze to
make sure conditions are still correct.

And we test as much as we can afford. In stand alone programs, we can afford
to test everything. If we code a widely used object, we had better make sure
the design is such that we can live with less testing.

Designing for reusability is designing for what we think is a characteristic of
good coding. Which is not a primary goal at all.

 

[Dario]

1989 or 1987?

In 1987 I written the program.
My last correction to the same program was made
at September 8, 1989 17:56 (Italian local time).

- Dario

 

[Harley]

|
|
| > | NOTHING will run 10 years from now!
| >
| > You might want to qualify this by language.
| > (NOTHING written in ? will run 10 years from now!)
| > Be careful, there are people out there with 10 year old software that is
| > still running.
|
| Correct - most of the software I work with is older than that.
|
| But if we are talking about "reuseable", I wonder what we should be
looking for.

My GUESS is inheritance, and polymorphism.

| Do we worry about plugging in the algorithm used to determine
depreciation so
| we don't have to analyze it again?
|
| Coding it is simple in any language, so I am guessing we are talking about
| keeping analysis and testing down. Except we will still need to analyze
to
| make sure conditions are still correct.
|
| And we test as much as we can afford. In stand alone programs, we can
afford
| to test everything. If we code a widely used object, we had better make
sure
| the design is such that we can live with less testing.

A business rule should be able to be tested outside the system
One of the suggestions in extreme programming is that you have a test driver
BEFORE you start coding.
System integration testing is still a requirement, but the test driver
should have uncovered any problems not associated with integration issues.
You still have an Oops issue, but the Opps should be associated with the
integration, not the functionality of the object.

| Designing for reusability is designing for what we think is a
characteristic of
| good coding. Which is not a primary goal at all.

I think this is a personal preference, like a style issue.

 

[Marco van de Voort]

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.

Mathlab? The only one I can think of being around over 15 years

 

[pete kirkham]

Mathlab? The only one I can think of being around over 15 years

FORTRAN. I've reused FORTRAN aerodynamics models that were 30+ years old
because they captured the domain model and the domain model hasn't changed.

LISP. I've reused LISP symbolic math processing models were 20 ish
years old because they captured the domain model and the domain model
hasn't changed.

Java was designed for portable GUIs, though is a lot more general
purpose now. Does your domain model map well to the constructs in Java?
Even if you can reuse a GUI in 20 years time, Java swing will look as
old to a user then as MSDOS 3 does to a OS X user now.

C models the architecture of a defunct hardware platform, and maps well
enough to other hardware platforms to give performance efficiencies.

The closer a language is to the language of your domain model, and the
better the the representation of the domain you produce, the longer your
software will by usefully reused.


Pete

 

[Alistair Maclean]

What about ruby, perl, various assembly groups, applescript, delphi,
ada, awk, dylan, eiffel, forth, fortran, icon, lsip, logo, modula2,
oberon, php, scheme, smalltalk, prolog, etc.?

A truly astute troll would have included at least the above.

A with-it truly astute troll would have mentioned Rebol.

 

[Marco van de Voort]

FORTRAN. I've reused FORTRAN aerodynamics models that were 30+ years old
because they captured the domain model and the domain model hasn't changed.

LISP. I've reused LISP symbolic math processing models were 20 ish
years old because they captured the domain model and the domain model
hasn't changed.

Don't be annecdotical. Reuse all code you rewrite now, and something
that will be in major use then (so that reusing makes sense at all)

I can only think of two possible candidates. TeX, and Mathlab, both in a
different realm. I wouldn't dare to bet on another one.

 

[JerryMouse]

Harley wrote:



Just keep it as a rule of thumb. If something made today
runs 10 years from now it is either pure luck or a dead
slow organization. If you expect the world to go on, you
oraganize your software so it can go along.

The fact that 15 years old Cobol (or C or PL/1 or UniFace)
software is still out there is no *proof* that it has
outlived time. Maybe it's is just written in a way that
makes it impossible to move on.

If you work for a large organization (more than 100,000 employees), I'll
wager dollars to donuts your paycheck was produced by a COBOL program that's
more than twenty years old (assuming your company has been around that
long).

A prudent company wants a piece of software - like a building - to just sit
there and do its job. While 'ancient' programs do have to have maintenance
from time to time, there's not a lot of maintenance to do on a General
Ledger program (whose basic rules have remined unchanged since the 16th
century).

 

[Harley]

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

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

| COBOL has had a resurgence recently - question is whether it will hold up
| for 15 more years....Probably 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?

 

[Peter E.C. Dashwood]

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.

 

[Kevin D. Quitt]

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.

I have product out there that's 30+ years old and still running. All in
assembly. Perfectly portable.

 

[Kevin D. Quitt]

Clearly the language of choice is MIX. Completely documented and free.
Reuse on new hardware would require only a small program whose inputs and
outputs are clearly and completely prescribed.

 

[Kevin D. Quitt]

And don't forget - a Real Programmer can write FORTRAN in any language.

 

[JerryMouse]

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

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

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


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".

Nah, a better definition is 'continued use.' You know, like it functioned in
the past, it functions now, and we have every reason it will continue to
function in the future.

 

[Roedy Green]

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.

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.

 

[jce]

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.

Typically it is not the code that is obscure. Code in PL/I, COBOL etc etc
is generally easy to read.
What locks a business rule in place is the Parent of ALL business rules:

"Business rules cannot change, after all, they are business rules".

I've seen code 15 years old that is perfectly understandable - we just
cannot find anyone to explain the "why".
I've seen code 15 years old that is perfectly understandable and continues
to do what it was supposed to and no one actually has asked for it to be
changed (outside of additional auditing information that was added in early
90's and again in the 00's).

So, to summarize, the "why" is often more important than the "how".
Flexibility is important if (a) It really is needed and (b) It doesn't
become bigger than the problem. KIS.

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.

The problem here is that they don't know what the old source was doing and
nothing more. An old employee of ours actually managed to lose some 5 year
old source code once. We knew what it did and we rewrote it...comparative
tests showed all was well. No problem.

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.

Absolutely. But we want to have the annotated cliff notes that give the
summary of what it is doing it for.

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

All the things I see are definite improvements for readability, the enhanced
for loop and autoboxing. I'm not sure on the metadata front because most of
that "boilerplate" code is generated anyhow - it's just more hidden.
All these things though are just details. Nothing substitutes a good design
and it will be just as easy to write crap 1.5 as it was to write crap 1.1.
It's kind of like literature. We can remove grammatical constructs, reduce
words and make things nice and simple like Harry Potter....but 100 years
from now people will still be figuring out Shakespeare and it's
quirks...whilst Harry Potter gets studied at "alternative" colleges....It's
the grand picture that makes something important with value that will last


JCE

 

[Richard Bos]

COBOL has had a resurgence recently - question is whether it will hold up
for 15 more years....Probably 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?).

I don't know what's wrong with not being bleeding-edge (apart form Not
Being Cool In The Eyes Of The Press, to which I say: Pfffrrrrttt...),
but I can tell you exactly what's wrong with being bleeding-edge: the
blood tends to be yours.

Anybody remember 4GL? Prolog? Jav... oops <g>.

Richard

 

[Paul Hsieh]

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.

Well, C will be around in 15 years in the same sense that COBOL is
still with us today. But probably something that should be pointed
out is that there are very few C compilers out there that don't also
support C++. There are very few if any universities teaching computer
science that teach C but not C++. So you could easily make a
strategic decision between C and C++ according to what makes sense for
you today, and certainly both will still exist in some way shape or
form 15 years from now.

That said, Java certainly has enough momentum today to suggest it will
probably exist in 15 years. Though whether or not it will supplant
C++ or other alternatives is too hard to see. The problem with Java
is that if it fails to continue to gain momentum, it might very
quickly be relegated to that of a niche market. I won't make a call
as to which way I think it will go, but I think its fair to say that
both (dominance over C++, or relegation to a niche) are possible. I
think its very unlikely that it will completely disappear in 15 years.

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. In 15
years, Pascal will probably be completely dead, and the COBOL
community will be reduced even from the size of today's community
(human mortality alone will guarantee this.)

 

[Scott Condit]

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]

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