software engineering and the notion of authorship

software engineering and the notion of authorship

[Fergus Henderson]

In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:

>To me this "ego-centered" style of programming is deadly.  It promotes a
>situation where in a big project code is owned by individuals.

I agree consistency is very important, as is maintainability.
It is essential to make sure that the overall design is consistent.
It is also essential that every part of the system is sufficiently
clear, well-documented, and so forth that any programmer could make
modifications to that part of the system, or take over responsibility
for that part of the system, and consistency of style is important
in facilitating this.  But I'm not convinced that recording
authorship or assigning areas of responsibility is a bad idea.

>you lose the advantages of working as a team.

Teamwork has it's own disadvantages.  In particular, productivity goes
way down!  (See "The Mythical Man-Month".)  If there is a problem
in a particular piece of code, it makes sense for the expert on
that subsystem to be the one to fix it.  They'll be able to do
it quicker, and with less likelyhood of error, than someone who
is not an expert on that subsystem.  It also makes sense for the
expert on a subsystem to be part of the code review team for any
changes to that subsystem, and assigning some degree of responsibility
to the expert can increase their motivation to do a good job of
code review.  Of course you need to make sure that the code is
sufficiently consistent, well-documented, etc. that anyone can _become_
the expert, when and if necessary.  But it's impossible for everyone
to be the expert on everything.

>in the GNAT project ...  You absolutely cannot tell
>who wrote code from its style, and indeed we strongly discourage the notion
>of authorship (we never for example attach names to units). Sure in practice
>certain people know certain code well and our informally the experts in
>particular areas, but if you look at the revision histories, you will see
>that all sorts of people work in all parts of the system.

What's wrong with recognizing the role of these informal experts?

>In my experience, as in sports, this team
>spirit is a key factor in maintaining a high level of motivation.

As in sports, I think it is useful to assign individuals particulars
areas of responsibility.  In Australian rules football, a team has
forwards, a backline, centers, and on-ball players (rovers, a ruckman
or two, and so forth).  It's not just a mob.

And while team spirit is important, so is individual motivation, and
a little bit of competition between players is a good thing, so long
as they're competing for success in meeting the team's objectives,
not competing for the ball.  A team plays better if they have a good
reserves team, with players competing for spots in the team.  And
players within a team compete for the team's best-and-fairest awards.

The important thing, IMHO, is finding the right balance.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[Fergus Henderson]

Jakob Engblom <engblojb@tick.infomatik.uni-stuttgart.de> writes:

>Ego-less programming is absolutely necessary to produce large functioning
>software. Or at least to maintain it later.

That's a slogan.  If you have some justification for it, please state it.

>> 					 If there is a problem
>> in a particular piece of code, it makes sense for the expert on
>> that subsystem to be the one to fix it.  They'll be able to do
>> it quicker, and with less likelyhood of error, than someone who
>> is not an expert on that subsystem.  
>
>Yeah, but the real problem comes 10 years down the road, when the experts
>have quit or died or moved to other projects and plain do not remember the
>wonderfully complicated code they created back in '96... 

If the code is clear, well-written and well-documented -- you should
use code reviews to ensure this -- then I don't see why attaching
authorship labels or assigning clear areas of responsibility is going
to cause you problems 10 years down the road.

>Using a "just complicated enough to do the job", "ego-less" programming style,
>makes it much easier for the new maintenance developer working with the
>program in 2006... the savings in the long run far outweigh the lack of
>"personal style" in the code. 

Of course you should not make the code more complicated than is necessary. 
No self-respecting computer scientist or software engineer would
suggest otherwise.  I'm not arguing for personal style -- I agree that
consistency makes maintenance easier.  What I am arguing for is some
degree of personal responsibility.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[The Amorphous Mass]

On Mon, 8 Jul 1996, Jakob Engblom wrote:

> !!!! SUPEr!!!!!
> 
> Only in software do we even think of accepting personal style like... it would
> be quite devastating in any other industry if an engineer insisted on using 
> left-handed instead of right-handed bolts "because I feel creative today"..
> things have to fit together, and TEAM WORK is the essential part of any
> programming project.

  I have a simple question:  Do we all mean the same thing by 
"programming style?"  It seems that the people supporting individual 
style are assuming that there are *some* coding standards being followed, 
and the "style" boils down to formatting idioms and whether they prefer 
for, while, do-while, etc, or the _exact_ way they name variables (for 
example, if the convention is To_Write_Variables_This_Way then one 
person's List_Of_Items will be another person's Item_List, etc).  The people 
dissing it seem to think that it implies that no standard, or no 
significant standard is being followed.  Using a left-handed bolt one 
day "because I feel creative" is like writing a module in SNOBOL one day 
"because I feel creative."  It doesn't have anything to do with the 
particular coding idiom that a programmer uses (which should be 
_consistent_:  it is a means of expression, not a whim), and it doesn't mean 
that the idioms can't be standardized to a certain extent, and it certainly 
doesn't mean that one person cannot read another person's code.  I 
learned C from a textbook whose formatting style I immediately disliked, 
but which I was nevertheless quite able to read.  Now I can see both Mr. 
Dewar's and Mr. Henderson's side of this issue -- I'm just getting the 
feeling that not everyone is talking about the same thing.
  If comments and documentation are counted as part of the code I would 
be amazed to hear that there is a single project of any significant size 
where it is impossible to tell who wrote the code, considering that 
writing styles tend to be individual.  Especially if the comments go into 
any depth. :-)

James Robinson.........................................james-robinson@uiowa.edu
   "To be prepared against surprise is to be /trained/.  To be prepared for
   surprise is to be /educated/."  --James Carse, _Finite_and_Infinite_Games_

Re: software engineering and the notion of authorship

[John Byerly]

Jakob Engblom wrote:
>
> Yeah, but the real problem comes 10 years down the road, when the experts
> have quit or died or moved to other projects and plain do not remember the
> wonderfully complicated code they created back in '96...

That's why we document code.  Software engineering is the only engineering
discipline that considers documentation to be optional.  And even when documents
are produced, they are almost never updated after the code is written.

Speaking as someone who always seems to get stuck maintaining code, I find that
something as simple as comments go a long way toward making my job easier.

> Using a "just complicated enough to do the job", "ego-less" programming style,
> makes it much easier for the new maintenance developer working with the
> program in 2006... the savings in the long run far outweigh the lack of
> "personal style" in the code.

I disagree.  I started my software engineering career maintaining undocumented
FORTRAN code that was about as ego-less as you get and the thing was a nightmare.
More recently, I have maintained well commented, C++ code that was created using
a style that was unfamiliar.  This experience was much less painful.

> Only in software do we even think of accepting personal style like... it would
> be quite devastating in any other industry if an engineer insisted on using
> left-handed instead of right-handed bolts "because I feel creative today"..

That is why this is called _soft_ware.  To a certain extent, we have more
flexibility in creating our product than, say, a mechanical engineer.  In a
strict sense, however, our deliverables are object files, libraries, executables,
etc., which had better match the specifications.  This is the "right-handed bolt".

> things have to fit together, . . .

Quite true.  That is what an Interface Specification is for.


__________________________________________________________________________
John A. Byerly                            Which way to Flower Mound, TX?
The Dalmatian Group, Inc.
User Interface Specialists                Currently on site at:
jbyerly@dalmatian.com                       Motorola -- Chandler, AZ

Re: software engineering and the notion of authorship

[Robert Dewar]

James Robinson says

"  If comments and documentation are counted as part of the code I would
be amazed to hear that there is a single project of any significant size
where it is impossible to tell who wrote the code, considering that
writing styles tend to be individual.  Especially if the comments go into
any depth. :-)
"

Try looking at the GNAT souces, you may be amazed :-)

Re: software engineering and the notion of authorship

[Jakob Engblom]

Fergus Henderson wrote:
> 
> In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:
> 
> >To me this "ego-centered" style of programming is deadly.  It promotes a
> >situation where in a big project code is owned by individuals.

Ego-less programming is absolutely necessary to produce large functioning
software. Or at least to maintain it later.

> 					 If there is a problem
> in a particular piece of code, it makes sense for the expert on
> that subsystem to be the one to fix it.  They'll be able to do
> it quicker, and with less likelyhood of error, than someone who
> is not an expert on that subsystem.  

Yeah, but the real problem comes 10 years down the road, when the experts
have quit or died or moved to other projects and plain do not remember the
wonderfully complicated code they created back in '96... 

Using a "just complicated enough to do the job", "ego-less" programming style,
makes it much easier for the new maintenance developer working with the
program in 2006... the savings in the long run far outweigh the lack of
"personal style" in the code. 

> >in the GNAT project ...  You absolutely cannot tell
> >who wrote code from its style, and indeed we strongly discourage the notion
> >of authorship (we never for example attach names to units). Sure in practice
> >certain people know certain code well and our informally the experts in
> >particular areas, but if you look at the revision histories, you will see
> >that all sorts of people work in all parts of the system.

!!!! SUPEr!!!!!

Only in software do we even think of accepting personal style like... it would
be quite devastating in any other industry if an engineer insisted on using 
left-handed instead of right-handed bolts "because I feel creative today"..
things have to fit together, and TEAM WORK is the essential part of any
programming project.

/jakob

-- 
----------------------------------------------------------------------------
 Jakob Engblom. Computer Science Student @ Uppsala University, Sweden 
                 presently an ERASMUS exchange student in Stuttgart, Germany
 email Uppsala: jakob@docs.uu.se       
 email Stuttgart: engblojb@tick.informatik.uni-stuttgart.de
 homepage: http://www.csd.uu.se/~jakob

Re: software engineering and the notion of authorship

[Peter Hermann]

Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:

: >To me this "ego-centered" style of programming is deadly.  It promotes a
: >situation where in a big project code is owned by individuals.

: I agree consistency is very important, as is maintainability.
: It is essential to make sure that the overall design is consistent.
: It is also essential that every part of the system is sufficiently
: clear, well-documented, and so forth that any programmer could make
: modifications to that part of the system, or take over responsibility
: for that part of the system, and consistency of style is important
: in facilitating this.  But I'm not convinced that recording
: authorship or assigning areas of responsibility is a bad idea.

Thank you for your contribution (you are saving my time  ;-).

Special topic "authorship": this has revealed to be one of the
most important properties of our systems. Each routine has
short "date/author/topic"-comments of creation and all subsequent updates.

[snip]
: And while team spirit is important, so is individual motivation, and
[snip]
: The important thing, IMHO, is finding the right balance.

agree

I also agree to most of the rules given in "Ada Quality and Style"
and it is a fun to read this document because it is 
spreading a feeling of deep SE-experience of its authors.
OTOH, "honny soit qui mal y pense", I think it is a bad idea
to impose EXTRA rules on human beings which do not have an important
justification.

E.g. it is of utmost importance to request variable names
which bear its exact meaning, it is not at all important 
to force a programer to_type_in_any_capital_letters
when he chooses to be lazy like me ;-)

That's why Ada is so great with its minimum
consens of absolute necessities at the man-machine-interface.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: software engineering and the notion of authorship

[Richard A. O'Keefe]

fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>>Yeah, but the real problem comes 10 years down the road, when the experts
>>have quit or died or moved to other projects and plain do not remember the
>>wonderfully complicated code they created back in '96... 

>If the code is clear, well-written and well-documented -- you should
>use code reviews to ensure this -- then I don't see why attaching
>authorship labels or assigning clear areas of responsibility is going
>to cause you problems 10 years down the road.


Fergus and I see eye-to-eye on many points.
However, he is working in a project with a small number of brilliant
programmers who are good at writing comments.

I had to maintain a large chunk of code which had only one comment (well,
I tell a lie, there were two: a commented out chunk of code -- with no
reason -- and the copyright notice) and a lot of one or two letter 
identifiers.  And code reviews were not a political practicality with
that piece of code:  it had been written by the _founder_ of the
company before I joined.  And he had left.

The "ego-less culture" that allows programmers to adopt a common style
is the same culture that is needed to allow the founder to submit his
precious work to other people's judgement.  I'm not arguing against
personal responsibility, only that the responsibility is responsibility
to *communicate*, and that adopting a common style in a project is one
of the things that *makes* the code clear.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: software engineering and the notion of authorship

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>Fergus and I see eye-to-eye on many points.
>However, he is working in a project with a small number of brilliant
>programmers who are good at writing comments.

Well, after that comment, our project is certainly going to have
trouble keeping the egos under control ;-) ;-) ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[Robert Dewar]

"We have a similar story here, a well known and extremely good assembler =
programmer wrote a large (>800 line) assembler package with one comment, =
next to a Jump-If-Equal statement he wrote the single comment "Jump here =
if not equal" - Wonderful!"


Of course, the fault lies here not with the programmer, but with he
environment and management which allowed this code to be placed into
the system. The programmer should have been forced to write in a reasonable
style or gotten rid of. There is no such thing as an "extremely god
a

Re: software engineering and the notion of authorship

[Robert Dewar]

Simon says

  "We have a similar story here, a well known and extremely good assembler =
  programmer wrote a large (>800 line) assembler package with one comment, =
  next to a Jump-If-Equal statement he wrote the single comment "Jump here =
  if not equal" - Wonderful!"


Of course, the fault lies here not with the programmer, but with the
environment and management which allowed this code to be placed into
the system. The programmer should have been forced to write in a reasonable
style or gotten rid of. There is no such thing as an "extremely good
assembler programmer" who would write a package of this size with no
comments. The real fault lies with a manager who did not realize this
and who tolerated such nonsense.

Re: software engineering and the notion of authorship

[Hugh Dunne]

Simon Johnston <skj@ACM.ORG> wrote:

>I had to maintain a large chunk of code which had only one comment =
>(well,
>I tell a lie, there were two: a commented out chunk of code -- with no
>reason -- and the copyright notice) and a lot of one or two letter
>identifiers.  And code reviews were not a political practicality with
>that piece of code:  it had been written by the _founder_ of the
>company before I joined.  And he had left.
>
>We have a similar story here, a well known and extremely good assembler =
>programmer wrote a large (>800 line) assembler package with one comment, =
>next to a Jump-If-Equal statement he wrote the single comment "Jump here =
>if not equal" - Wonderful!

Some of the (few) comments seen in the source code of a certain
Ada compiler vendor's run time system:

	"Go backwards or die!!!"
	"Stupid Ada!"
-- 
--------------- http://www.vjf.com/PUBLIC/86/27186.html ---------------
Hugh Dunne/Logica UK Ltd/Stephenson House/75 Hampstead Rd/London NW1 2PL
The above are strictly my own personal opinions  | dunneh@lhd.logica.com
and in no way reflect the opinions of Logica.    | +44 171 446-1608

Re: software engineering and the notion of authorship

[Paul Eggert]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> I had to maintain a large chunk of code which had only one comment ...
> and a lot of one or two letter identifiers.  And code reviews were not
> a political practicality with that piece of code:
> it had been written by the _founder_ of the company before I joined.
> And he had left.

I had to maintain a similar batch of code, and if I'm not mistaken it
was written by the same guy for his previous company.  It was a joy.
That guy really knew what he was doing, and his code taught me a lot of things.

But I had to write documentation describing the program so that
everybody else at our company could follow what was going on.
The documentation was considerably longer than the program that it described.

In extreme cases like this, the usual software engineering management
principles often don't work well.  And extreme cases are often the
most profitable ones....

Re: software engineering and the notion of authorship

[Ralph Silverman]

Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:

: >To me this "ego-centered" style of programming is deadly.  It promotes a
: >situation where in a big project code is owned by individuals.

: I agree consistency is very important, as is maintainability.
: It is essential to make sure that the overall design is consistent.
: It is also essential that every part of the system is sufficiently
: clear, well-documented, and so forth that any programmer could make
: modifications to that part of the system, or take over responsibility
: for that part of the system, and consistency of style is important
: in facilitating this.  But I'm not convinced that recording
: authorship or assigning areas of responsibility is a bad idea.

: >you lose the advantages of working as a team.

: Teamwork has it's own disadvantages.  In particular, productivity goes
: way down!  (See "The Mythical Man-Month".)  If there is a problem
: in a particular piece of code, it makes sense for the expert on
: that subsystem to be the one to fix it.  They'll be able to do
: it quicker, and with less likelyhood of error, than someone who
: is not an expert on that subsystem.  It also makes sense for the
: expert on a subsystem to be part of the code review team for any
: changes to that subsystem, and assigning some degree of responsibility
: to the expert can increase their motivation to do a good job of
: code review.  Of course you need to make sure that the code is
: sufficiently consistent, well-documented, etc. that anyone can _become_
: the expert, when and if necessary.  But it's impossible for everyone
: to be the expert on everything.

: >in the GNAT project ...  You absolutely cannot tell
: >who wrote code from its style, and indeed we strongly discourage the notion
: >of authorship (we never for example attach names to units). Sure in practice
: >certain people know certain code well and our informally the experts in
: >particular areas, but if you look at the revision histories, you will see
: >that all sorts of people work in all parts of the system.

: What's wrong with recognizing the role of these informal experts?

: >In my experience, as in sports, this team
: >spirit is a key factor in maintaining a high level of motivation.

: As in sports, I think it is useful to assign individuals particulars
: areas of responsibility.  In Australian rules football, a team has
: forwards, a backline, centers, and on-ball players (rovers, a ruckman
: or two, and so forth).  It's not just a mob.

: And while team spirit is important, so is individual motivation, and
: a little bit of competition between players is a good thing, so long
: as they're competing for success in meeting the team's objectives,
: not competing for the ball.  A team plays better if they have a good
: reserves team, with players competing for spots in the team.  And
: players within a team compete for the team's best-and-fairest awards.

: The important thing, IMHO, is finding the right balance.

: --
: Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
: WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
: PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

--
************begin r.s. response*************

	a closely related question is:
	if persons who are supposed to be
		programmers
	can usefully work in groups
	or teams
		were such persons not able
		to program individually...
	?

	generally,  one may suppose,
	those capable of programming
	individually would be accepting of
		individuality
	.

************end r.s. response***************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: software engineering and the notion of authorship

[Fergus Henderson]

I got a useful reply from Scott Ellsworth <fuz@deltanet.com> via email;
he said he wouldn't mind if I posted it.

> Assuming the original poster is not a doof, what I assume he means by 
> ego-less programming is simply programming for clarity, not cleverness.  
> Often, if someone's name is atattched to a product, they get possessive, 
> and try to do things in the most complex and clever way they know how.  
> This does not actually give them a better rep in most other people's 
> eyes, but inexperienced programmers often think it should.
> 
> Proper training can break someone of this, just like it can break them of 
> not commenting code that needs it, and proper code reviews can make 
> overly clever code be rewritten for clarity.  Of course, if the code is 
> time critical and needs to be faster, then clever is good.
> 
> Personally, I approve of pride of creation in most software projects, as 
> long as that includes the stated assumption that your creation will 
> become someone elses creation once you move to another project.

That reply explains to me some of the motivations behind ego-less programming
better than many of the other articles in this thread.

For the moment, I remain open-minded about whether or not recording authorship
is advantageous or disadvantageous overall.  One thing is certain, and that
is that knowing the dangers helps one to avoid them.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[Robert Dewar]

Ralph Silverman asks

        a closely related question is:
        if persons who are supposed to be
                programmers
        can usefully work in groups
        or teams
                were such persons not able
                to program individually...
        ?

        generally,  one may suppose,
        those capable of programming
        individually would be accepting of
                individuality

I have worked completely on my own (e.g. several complete operating systems
written for Honeywell and the first version of Macro-SPITBOL), in small
teams (SPITBOL 370 was a 2-person effort, Realia COBOL was a 3-peson
effort), and in larger groups (GNAT is a several person effort).

I see no real differences. In each case, an absolute standard of consistency
is essential throughout the program. Remember that one of the major needs
for consistency is for maintenance, and how many people developed a project
is rather irrelevant when considering maintenance needs (all the programs
I mention abvove have been maintained by multiple people over the years).

When you are working alone, you can of course set your own standards of
consistency, but in fact I see many 1-person programs that are a mightmare
(oops typo, but rather nice one, I will leave it in :-)          nightmare
of inconsistency. I couldn't possibly work that way myself.

When you are working together, you have first to agree on the standards
of consistency that you will use. That means you don't get to choose yourself
every detail, so what? For example, in the GNAT project, as I have mentioned
before, I was forced to change from ALL_UPPER_CASE_IDENTIFIERS to the more
usual Mixed_Case_Identifiers since that is what the team preferred. It was
awkward at first (you always find it easier to do what you are used to, and
to read code in the style you are used to), but it would never have occurred
to me to react to that awkwardness by insisting on continuing to SHOUT when
I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
style (now it would be hard to go back).

However, I see many programmers for whom not only does it occur to them to
react in this situation by insisting on using their own style, but they do it
and their management permits it. I am certainly capable of programming
individually, but I am definitely NOT willing to accept this particular
brand of individuality, not for a moment!

The team effort issue of course only applies to groups, but there is another
factor that I think is important. Whether you are working alone or in a
group, an elegantly structured and consistently presented source code is
a source of pride, and that is definitely a positive dynamic in any project.

Re: software engineering and the notion of authorship

[Andrew Gierth]

[This thread should never have been injected into comp.unix.programmer.
Would all respondents *please* take that into account. Followups set.]

Mike Curtis <curmi02@unix9.ingres.com> wrote:
>Robert Dewar wrote:
>------ <snip> -------
>> .... but it would never have occurred
>> to me to react to that awkwardness by insisting on continuing to SHOUT when
>> I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
>> style (now it would be hard to go back).
>> 
>
>Ah Robert, but if you were insisting on writing the code in Ada and everyone else 
>wanted to use C would you fall in with them so readily.
>
>Mike

Re: software engineering and the notion of authorship

[Mike Curtis]

Robert Dewar wrote:

------ <snip> -------
> .... but it would never have occurred
> to me to react to that awkwardness by insisting on continuing to SHOUT when
> I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
> style (now it would be hard to go back).
> 

Ah Robert, but if you were insisting on writing the code in Ada and everyone else 
wanted to use C would you fall in with them so readily.

Mike

-- 
Mike Curtis               tel: +44 1753 679935
curmi02@unix9.ingres.com  fax: +44 1734 442453
Computer Associates International