Future reuse of code

D

Donald Tees

Roedy Green said:
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
 
H

Harley

| On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
|
| >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.
 
D

Donald Tees

Peter E.C. Dashwood said:
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...

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
 
H

Howard Brazee

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

Howard Brazee

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

Harley

Snipped much of post.

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

lvirden

According to Thomas Gagné <[email protected]>:
: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/pbmplus_10dec1991.tar.gz
so that software is 12 years ago. I suspect that people still use that
distribution.
 
L

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

lvirden

According to Donald Tees <[email protected]>:
: 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.
 
M

Mark Gordon

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

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

Mark Gordon

On Mon, 04 Aug 2003 14:28:23 GMT

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.

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.

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......Sun goes belly up in 2006....Microsoft 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.
 
A

Alistair Maclean

JerryMouse said:
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.
 
J

jce

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 :)

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
 
J

John C. Bollinger

According to Thomas Gagné <[email protected]>:
: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/pbmplus_10dec1991.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
(e-mail address removed)
 
R

Roedy Green

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

Peter E.C. Dashwood

Harley said:
Snipped much of post.

|
| 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
"Requirements Gathering" phase was signed off...

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

Pete.
 
R

Roedy Green

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

Roedy Green

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

Roedy Green

Perhaps most amazing, this program was, and still is, written in...
Clipper.

This suggests another general principle. If you are interested in
longevity, write in a language supported by as many vendors as
possible. We have seen the demise of dBase, as the ball was passed and
fumbled with the decline of Ashton Tate.


Wirth might suggest always using a language simple enough that you
could fund your own compiler if necessary.
 
R

Richard Bos

According to Richard Bos <[email protected]>:
:
:> 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...),

Well, another thing is finding adequately trained staff, training materials,
etc.

Yes, that's another good point against being bleeding edge. You cannot
possibly have _adequately_ trained staff for a language that's less than
five years old, unless your definition of adequate is "just about good
enough to battle through the project", rather than, as it should be,
"quite good enough to get things done the right way".
Trying to find resources to get things done in the 'stable' languages
becomes harder (and more costly) as time goes on.

Snigger.

Richard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top