Re: Distinguishing type names from other identifiers

Re: Distinguishing type names from other identifiers

[Adam Beneschan]

Nick Roberts wrote:

> The technique I generally use for inventing a type identifier distinct from
> identifiers I might use for objects and parameters of that type is to make
> the type identifier one step more specific (and thus, usually, longer).
>
> The justification for using a longer identifier for the type, rather than
> for the objects and parameters, is that type identifiers are generally used
> less often in practical source text.
>
> For example:
>
>    type Hour_Of_Day is range 0..23;
>    type Minute_Of_Hour is range 0..59;
>    type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
>
>    function To_Seconds_Past_Midnight
>                    (Hour:    Hour_Of_Day;
>                     Minute:  Minute_Of_Day;
>                     Seconds: Seconds_Past_Minute) return Day_Duration;
>
> This example illustrates (I hope ;-) that the use of a plural or singular
> form for an identifier is not naturally to do with whether it denotes a
> type, an object, a parameter, a subprogram, or whatever, but rather with
> whatever concept it describes.  The choice of Seconds_Past_Minute is
> perhaps a little clumsy. . . .

After following this thread, and looking at this example, I really
wonder what the objection is to using _Type suffixes.  Several people
have objected to "_Type" on the ground that it doesn't add any
informational value to the name.  But do the extra words in the above
example add any value to the name, either?  I'm not convinced that
calling the type Hour_Of_Day is any more helpful to a programmer than
just calling it Hour or Hour_Type.

Of course, I could have picked a bad example to complain about, since
there could be a use for both "Minute_Of_Hour" and "Minute_Of_Day" or
"Minute_Of_Year" or "Minutes_Elapsed" types, or something like that.
But it seems to me that in many, many cases, there just isn't any
extra value to add to the name.  So *anything* you add, whether it's a
boring suffix like _Type or a boring prefix like The_, or something
less boring that appears to contain additional information as in the
above example, is still just "noise"---in essence, a kludge to keep
the compiler happy.

So if I'm right and anything you add is just noise, I think it may be
best to use a boring suffix like _Type.  The small advantage to this
is that it may make your names easier to remember.  If you use _Type
consistently, at least you have less information to carry around in
your head, instead of trying to remember something different for each
type: "Now, let's see, did I call this one _Number, or _Of_Day, or
_Of_Hour, or what?" leading to potential errors such as the one Nick
included in his above example.

                                -- Adam

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Tue, 13 Jan 1998, Adam Beneschan wrote:
> After following this thread, and looking at this example, I really
> wonder what the objection is to using _Type suffixes.  Several people
> have objected to "_Type" on the ground that it doesn't add any
> informational value to the name.  But do the extra words in the above
> example add any value to the name, either?  I'm not convinced that
> calling the type Hour_Of_Day is any more helpful to a programmer than
> just calling it Hour or Hour_Type.

I am in complete agreement.

> So if I'm right and anything you add is just noise, I think it may be
> best to use a boring suffix like _Type.  The small advantage to this
> is that it may make your names easier to remember.  If you use _Type
> consistently, at least you have less information to carry around in
> your head, instead of trying to remember something different for each
> type: "Now, let's see, did I call this one _Number, or _Of_Day, or
> _Of_Hour, or what?" leading to potential errors such as the one Nick
> included in his above example.

Also, in generic code (meaning, Ada generics) it isn't always appropriate
to use specificity to distinguish, since the entities are, well, generic.
If one is going to use a suffix, another question that comes up is what to
do with access types when you want them distinguished from the non-access 
version. In C (sorry, I am a C programmer too) I use capitalized intercap 
for type names, so a I might have names like CircListT, CircListPT. Ada 
programmers seem to dislike abbreviations, but I really don't like type
names like Circular_List_Access_Type. _Ptr might work, but I usually use 
that for variable names. What do people who use suffixes generally do?

-- Brian

Re: Distinguishing type names from other identifiers

[Michael F Brenner]

No, the main objection to hour_type is not redundant information,
but ugliness. The secondary objection is the lack of plurals, so
that it does not read like an English sentence. The redundancy, if
it were redundant instead of vacuous, would not be so very objectionable.

However, when stuff like _TYPE is added at the end of each type by
FIAT of a quality standard, you not only have changed the meaning
of quality from something that works well and is easily fixed to 
something that is regimented, but you also have lost the reliability,
lost the maintainability, and lost the desire to read that code.
It is no longer cool code.

Nothing affects maintainability more than a lack of desire to maintain it.

Re: Distinguishing type names from other identifiers

[Nick Roberts]

So the answer is ... interleave jokes in comments with your code! 
Programmers will love maintaining the code; and they'll have fun thinking
up more jokes to put in.  Interesting concept.

Something like

   for T in Fuel_Tank_Count'Range loop
      -- Did you hear the one about the Scotsman, the Englishman, and the
Irishman?
      Initialize_Fuel_Tank_Sensor(T);
   end loop;
   -- Well, there was a Scotsman, an Englishman, and an Irishman,
   -- and they were walking along a Dublin street one night, ...

and so on.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Michael F Brenner <mfb@mbunix.mitre.org> wrote in article
<69lael$90o@top.mitre.org>...
> 
> No, the main objection to hour_type is not redundant information,
> but ugliness. The secondary objection is the lack of plurals, so
> that it does not read like an English sentence. The redundancy, if
> it were redundant instead of vacuous, would not be so very objectionable.
> 
> However, when stuff like _TYPE is added at the end of each type by
> FIAT of a quality standard, you not only have changed the meaning
> of quality from something that works well and is easily fixed to 
> something that is regimented, but you also have lost the reliability,
> lost the maintainability, and lost the desire to read that code.
> It is no longer cool code.
> 
> Nothing affects maintainability more than a lack of desire to maintain
it.
> 

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Michael says

<<> However, when stuff like _TYPE is added at the end of each type by
> FIAT of a quality standard, you not only have changed the meaning
> of quality from something that works well and is easily fixed to
> something that is regimented, but you also have lost the reliability,
> lost the maintainability, and lost the desire to read that code.
> It is no longer cool code.
>>

Now here I disagree. If you have programmers (I don't care whether they
are maintaining code or building it), and their orientation is that they
react to quality standards by deciding that it means they cannot write
cool code, and they want to do their own thing, then the one and only
preferable solution is to get rid of these programmers. What you refer
to as regimentation is something that quality workers in all fields
must learn to accept. Yes, I realize that the programming field tends
to be full of mavericks who insist on writing neat cool code, but this
is a signal weakness of the field, not a strength.

In practice I find one of the advantages of Ada is that Ada tends to
encourage what you would like to call "regimented" environments, and 
thus to scare off the "cool neat code" crowd. 

Whether the rule of adding _Type at the end of type names is a good one
is one that should be debated on its merits, but Michael's contribution
quoted above seems to suggest that it should be rejected solely on the
basis that it is a rule. That is not a legitimate argument. Some quality
standards can indeed be absolute. Everyone agrees, or should agree that
consistency of code style is an important requirement in any project,
and some aspects of coding style can and should be absolute rules (for
a look at the absolute rules enforced by the GNAT project, look at the
style.adb unit, which is activated by the internal GNAT-project-only
switch -gnatg. We require the use of -gnatg in all GNAT code.

This switch enforces a number of rules ranging from the trivial (no use
of tab characters or trailing blanks in code) to more significant (all
subprograms except main programs at the program library level must have
separate specifications).

Note that I agree that enjoyment plays an important part in any work, and
that "desire to read that code" is important. But competent programmers
find that following "regimentation" makes code more uniform, and therefore
much pleasanter to read. 

Robert Dewar

Re: Distinguishing type names from other identifiers

[Michael F Brenner]

   > ... everyone should agree ...

Dr. Dewar, it is obvious that EVERYONE does not agree with you that
indendation rules have ANYTHING to do with quality. Let me make it 
perfectly clear, that something like indentation which tools can 
change at anyone's whim with zero effort cannot be something that
reduces the cost of software maintenance or the reliability of a
development effort. Nor does the addition of competent mavericks to
a team hurt that team, unless the politics of the team is aimed
somewhere other than in the direction of getting the bugs out of the
product. 

It is okay to espouse your beliefs, but it would be better to permit
the existence of other beliefs to co-exist with yours, and not be
so absolute as in the above quote phrase. 

There is a certain level of project where it becomes essential to 
stop measuring regimentation and volume, and instead measure the
things that make software maintenance more expensive. That is,
those things that cause the maintainer to spend more time analyzing
the impact of changes. 

As proof that gnat has evolved past the level where regimentation
can make it maintainable, we have the decision of ACT that is too
expensive to upgrade the current version of gnat for DOS, gnat 3.07, 
to a later version. Specifically, rather than becoming cheaper and
cheaper 
gnat is becoming more expensive to maintain. 

It would be worth addressing the fact that, despite using Ada,
gnat is becoming more expensive to maintain.

Possibly, the only way to make an Ada-95 program more expensive to
maintain is to DEFINE quality to be regimentation, and measure
that
regimentation rather than measuring things that decohese the
design and couple the code. 

How much of the increase in the maintenance expense of gnat is 
attributable to the philosophy of regimentation of SYNTAX,
rather than measuring the semantic problems?

This question is worth thinking out seriously, rather than 
politically. The answer might support your view or other views.
But there are many projects that would like to ensure they
are measuring the right thing.

Certainly, enforcing syntax rules is trivial with the right tools.
But reducing the number of references to global variables, making
more types limited private, making more variables local, and
making more packages pure might take away more bugs in the gnat
code than continuing to enforce those syntax rules. It is worth
an experiment or two.

Mike Brenner

Re: Distinguishing type names from other identifiers

[Robert Dewar]

<<It is okay to espouse your beliefs, but it would be better to permit
  the existence of other beliefs to co-exist with yours, and not be
  so absolute as in the above quote phrase.

  There is a certain level of project where it becomes essential to
  stop measuring regimentation and volume, and instead measure the
  things that make software maintenance more expensive. That is,
  those things that cause the maintainer to spend more time analyzing
  the impact of changes.>>

Well I disagree, and as I say, as a software manager, I simply would
not tolerate anyone who had this kind of attitude. I find this kind
of chafing under rules to be very damaging to group productivity.
But I am just telling you what my experience is. You certainly will
not persuade me to change my views. At the same time, I am not saying
everyone else has to share these views. There are obviously a lot of
people around who prefer the let-me-hack-away-using-my-own-style
school of thought. All I am saying is that I don't want such people
around my projects.

For example, if someone chafed at using the standard indentation prescribed
by a project, and used there own standard, grudgingly using some tool to
change to the standard rules, I would regard this as evidence of EXACTLY
the kind of attitude that I would want to weed out right away. Avoiding
the evils of code ownership and idiosyncratic styles is for me a key
part of software management

<<As proof that gnat has evolved past the level where regimentation
  can make it maintainable, we have the decision of ACT that is too
  expensive to upgrade the current version of gnat for DOS, gnat 3.07,
  to a later version. Specifically, rather than becoming cheaper and
  cheaper gnat is becoming more expensive to maintain.>>

Chuckle, chuckle, Michael manages to climb on his DOS hobby horse in
very surprising ways :-)

The claim of course is complete nonsense. gnat has not become unmaintainable.
The reason there is no new update of the DOS versoin is that we have invested
zero effort in producting a new version. I am afraid that we have not been
able to manage to make GNAT so maintainable that it maintains itself. As I
have many times pointed out, updating GNAT to current sources is not a big
task, but we have no interest in spending any time at all doing it, since
we see no customer interest in DOS at all. Michael sounding off on CLA
does not generate revenue :-)

<<How much of the increase in the maintenance expense of gnat is
  attributable to the philosophy of regimentation of SYNTAX,
  rather than measuring the semantic problems?>>

There is no such increase, and it is absolutely clear to us that what
worries you as "regimentation of syntax" is one of the reasons that we
are able to be as productive as we are in the continued development
and maintenance of GNAT.

<<Certainly, enforcing syntax rules is trivial with the right tools.
  But reducing the number of references to global variables, making
  more types limited private, making more variables local, and
  making more packages pure might take away more bugs in the gnat
  code than continuing to enforce those syntax rules. It is worth
  an experiment or two.>>

This is apples and oranges. Of course everyone agrees that code should
be written in a clear manner avoiding nasty things etc etc, but you cannot
legislate good code by automatic rules.

On the other hand, uniformity of syntax is NOT about reducing bugs. It is
about creating a code base that everyone in the group feels comfortable
with, so that you avoid the phenomenon, all too common I am afraid in many
large projects, of individuals "owning" pieces of the code and (a) not
wanting anyone else to mess with their parts and (b) not being willing to
mess with other peoples code.

The bottom line here is that of course opinions differ. I find Michael's
contributions on this issue constructive because they form a nice example
of *exactly* the attitudes that I think are important to avoid!

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Note as an interesting postscript to this discussion of enforced coding
styles, that a very common request for enhancement of GNAT is an official
feature similar to -gnatg.

Indeed, quite a few of our customers are using -gnatg even though we advise
against it (we advise against it, becuase (a) it makes the compiler 
non-standard, e.g. allowing compilation of new children of Ada and (b) we
feel free to change this at any time, typically by adding new requirementsw
which you might or might not like)).

We definitely plan some limited capability of this type for style enforcement
available as a user capability in the future.

Note that you can also use external tools, such as AdaAssured to do this
kind of style checking.

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 16 Jan 1998, Robert Dewar wrote:
> This is apples and oranges. Of course everyone agrees that code should
> be written in a clear manner avoiding nasty things etc etc, but you cannot
> legislate good code by automatic rules.
> 
> On the other hand, uniformity of syntax is NOT about reducing bugs. It is
> about creating a code base that everyone in the group feels comfortable
> with, so that you avoid the phenomenon, all too common I am afraid in many
> large projects, of individuals "owning" pieces of the code and (a) not
> wanting anyone else to mess with their parts and (b) not being willing to
> mess with other peoples code.

It is this attitude, apparently very common amongst Ada programmers, and
espoused regularly on this newsgroup, that makes me like the Ada community 
more than any other. While I haven't been around as long as Robert Dewar, 
and disagree with him on the "_T" as noise assessment :-), his
characterization of the way many software projects mismanaged is eerily
familiar to me, and his prescription for solving some of these problems
by firing the losers who have to do things their way seems eminently
reasonable. It is also, unfortunately, contrary to the way most projects
I've worked in are run. 

It's this kind of post that will turn me into an Ada fanatic :-)

-- Brian

Re: Distinguishing type names from other identifiers

[nabbasi]

>
>On 16 Jan 1998, Robert Dewar wrote:
>> 
>> On the other hand, uniformity of syntax is NOT about reducing bugs. It is
>> about creating a code base that everyone in the group feels comfortable
>> with, so that you avoid the phenomenon, all too common I am afraid in many
>> large projects, of individuals "owning" pieces of the code and (a) not
>> wanting anyone else to mess with their parts and (b) not being willing to
>> mess with other peoples code.

I view the idea of a programmer owning a particulare part of the 
software (say a subsystem, or a number of packages or a number of clases etc..)
as more of having personal responsibility for what they are working on, NOT
as being not wanting others to touch their code or they not wanting to 
touch someone else code.

This is why I don't agree that each programmer should not "own" what they
are working on. again, owning here means to me that they are "responsible" 
for that they are working on, it is a positive thing, not a negative one.

Otherwise, it becomes programming by committe, no one is responsible for
any thing going wrong, becuase no one owns the code. If one part of the 
software is not working, one can't hold any person responsible, this seems
to me to allow lazy and bad programmers to ride on the shoulder of better
programmers.

The best situation is where programmers are held responsible for what they
write, to be held responsible for what you write must imply ownsership
of the code, but at the same time, having the code such that any one 
can easily read each other's code or even modify each other code if the need
arises. I beleive in having common style and common standards, but at the
same time, owning what you write.
 
just my 1.88 cents offcourse. 

thanks,
Nasser

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Nasser says

<<Otherwise, it becomes programming by committe, no one is responsible for
any thing going wrong, becuase no one owns the code. If one part of the
software is not working, one can't hold any person responsible, this seems
to me to allow lazy and bad programmers to ride on the shoulder of better
programmers.
>>


The trouble is that if your view is that one particular person is
*the* person responsible for fixing a bug if it occurs in unit X, then
what if that person is on vacation, or suddenly leaves the company.
Inevitably this kind of ownership discourages others from learning
that code, or fixing it, and, as you note, taking responsibility for it.

My ideal of a project is that everyone takes responsibility for everything,
and that every part of the system has more than one person knowing it 
well enough to fix or modify things. Ideally testing procedures should
be set up to minimize the problem of introducing bugs into a system
but if someone *does* introduce a bug, then what should happen is that
they feel a strong sense of responsibility to the little community that
is the project they are involved in, and rush to fix the problem.

Furthermore, everyone needs to work together, so that if someone does
make a mistake, other people's reaction is to work to help sort it out,
rather than sit around being annoyed.

Creating a sense of community that achieves this ideal is not easy, but
it is definitely possible. Agreeing to a standard set of coding conventions
is just one element in acheiving this.

A good test for me is how the "owner" of unit A reacts if someone else
fixes a problem or makes a modification in unit A. All to often the
reaction is a defensive one ("what's this guy doing messing with my code?").
What you are aiming at is that the reaction is more like "great, thanks,
now I don't have to fix that bug myself".

Robert Dewar

who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885126007@merv>, dewar@merv.cs.nyu.edu says...
>
>Nasser says
>
><<Otherwise, it becomes programming by committe, no one is responsible for
>any thing going wrong, becuase no one owns the code. If one part of the
>software is not working, one can't hold any person responsible, this seems
>to me to allow lazy and bad programmers to ride on the shoulder of better
>programmers.
>>>
>
>
>The trouble is that if your view is that one particular person is
>*the* person responsible for fixing a bug if it occurs in unit X, then
>what if that person is on vacation, or suddenly leaves the company.
>Inevitably this kind of ownership discourages others from learning
>that code, or fixing it, and, as you note, taking responsibility for it.
>

But this is not a problem, we always face this, and it never caused much 
of a problem, when once person leaves, another takes over his/her tasks.
this does not just happen in software it happens in ever other field.

I am not saying one should not be familiar what what others are working on,
but having 2 or more programmers working on the code at the same time JUST
to cover the basis in case one quits or goes to vacation seems too drastic
a solution for me.

>My ideal of a project is that everyone takes responsibility for everything,
>and that every part of the system has more than one person knowing it 
>well enough to fix or modify things. 

well, having 2 or more programmers working on the same peice code 
could not work well. It is like having 2 cooks making the same 
meal. or 2 or more painters drawing on the same picture at the same time. 

I for one, could not work on a package or class, where 
I came in the morning to see my code has been modifed, and I could 
never modify someone else code on the project without a very good 
reason (customer on the phone screeming, the owner of the package is out
sick, etc..) and without at least asking first if at all possible.

I am all for the team spirit and the little community feeling, but 
I beleive that each programmer should be assigned a task, and they 
own up to it, and they are resposible for it and no one else. 

After all in Ada, of all the languages, encourages having a well defined
interfaces between parts of the software system. What should happen then, is 
after agreeing on the interfaces between packages, each programmer will own
1 or more packages, and they implement these to the interface agreed upon.

I am resposible for the implementation and testing and fixing bug in my
package, I would not want someone to be fixing my bugs for me, or modifying
my package as long as I own it. Offcourse there will be design meeting and
continue groups discussions, but it is known who owns what.

>Ideally testing procedures should
>be set up to minimize the problem of introducing bugs into a system
>but if someone *does* introduce a bug, then what should happen is that
>they feel a strong sense of responsibility to the little community that
>is the project they are involved in, and rush to fix the problem.
>

BUT who should rush to fix a bug that person A caused? Who is better to 
fix a bug made by person A that person A? offcourse if A asks for help,
or code review from another person on the team, I'll be the first to volunteer
to help look at the problem with person A untill the problem is solved, 
but having every one in the team somehow be held resposible for a 
problem caused by person A does not seem right to me. 

>Furthermore, everyone needs to work together, so that if someone does
>make a mistake, other people's reaction is to work to help sort it out,
>rather than sit around being annoyed.
>

Offcourse they should help each others, but there is a big difference
between helping each others, and between having no one owning anything,
then where is the personal resposibilty?

>A good test for me is how the "owner" of unit A reacts if someone else
>fixes a problem or makes a modification in unit A. All to often the
>reaction is a defensive one ("what's this guy doing messing with my code?").
>What you are aiming at is that the reaction is more like "great, thanks,
>now I don't have to fix that bug myself".
>

But if they don't fix their own bugs, they will not learn not to do it again !

Soory Dr Dewar, I can't agree with your style of running a software
project. it is obviously has been successfull for you and your team, but  
I like to think where I work that I am held responsible for my bugs, and I 
should be the one to fix them, and If I need help, I'll ask, and if I am
working one some part of the system, I do not want others to be working
on it at the same time,(they must have their own parts of the system
to write that will keep them busy!) this is just practical thing for me, I 
just don't see how a group of programmers be all working on the same 
piece of code at the same  time. it just plain cofusing to me.


Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<well, having 2 or more programmers working on the same peice code
could not work well. It is like having 2 cooks making the same
meal. or 2 or more painters drawing on the same picture at the same time.

I for one, could not work on a package or class, where
I came in the morning to see my code has been modifed, and I could
never modify someone else code on the project without a very good
reason (customer on the phone screeming, the owner of the package is out
sick, etc..) and without at least asking first if at all possible.

I am all for the team spirit and the little community feeling, but
I beleive that each programmer should be assigned a task, and they
own up to it, and they are resposible for it and no one else.
>>

OK, there it is, both negative aspects of code ownership! 

In case my position is not clear, I regard both viewpoints as unfortunate
in the quest to maintain maximum code quality and productivity. In
particular, if you have this level of code-ownership viewpoints, you
will very seldom get people reading other people's code in a routine
manner. It is this many-eyes-on-the-code phenomenon which is valuable
for code quality. Also, if there is this much code ownership going
on, then you are bound to get divergence in style, further contributing
to people being unwilling to look at, let alone work on, other people's
code.

I quite understand that a lot of programmers feel as nabassi does, but
for me, one of my absolute requirements in a software project, is that
this attitude cannot be permitted, and I could not have people with this
attitude working on projects that I was managing.

It's a matter of style, but I can certainly tell you that even though you
can't really imagine that it works, my experience is that the "egoless"
style in which people do not own the code they write, gives MUCH better
results than the code ownership model -- you should try it some time!

Robert Dewar

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885163403@merv>, dewar@merv.cs.nyu.edu says...
>
>OK, there it is, both negative aspects of code ownership! 
>

well, you call it negative I call it positive :)

> In
>particular, if you have this level of code-ownership viewpoints, you
>will very seldom get people reading other people's code in a routine
>manner. 

not at all. this is where code reviews comes in, this is where weekly
design meetings comes in, this is where white board brain storming comes in,
this is where good documenations by each programmer of what they are working
on comes in. this is being done all the time in all organizations (at least
I hope it is done).

owning something DOES not mean that no one can look at each others work, it
just means programmers repsect each others work, and giving some feeling
of ownership to one's work will motivate programmers to improve their 
work more, since their name on on their work going out of the door.

If my name is on a package, I am much more likely to try more to make
sure there is nothing wrong with it, if the department name is stamped on 
every thing leaving that department, one is less likely to try to do the best,
since if something goes wrong, no one is responsible, it is the "department"
or the "group" that is resposible. 

>It is this many-eyes-on-the-code phenomenon which is valuable
>for code quality. 

sure, I agree, again, this is what code reviews are for.  you can have
as many eyes as you want looking at the code, but my point is that, at the
end of the day, I want to see one name on that package of who is responsible
for it, I do not want to see a "group" name on it. at any one point of time,
there should be a person responsible for that piece of code if at all 
possible.

>Also, if there is this much code ownership going
>on, then you are bound to get divergence in style, further contributing
>to people being unwilling to look at, let alone work on, other people's
>code.
>

not really, this is what code standards are for. each group will agree on some
standard and convention and use that before they start implementation. 
this is a common thing that is done. (at least I hope so)

>I quite understand that a lot of programmers feel as nabassi does,

if many feel like me, then there must be something right about it :)

> but
>for me, one of my absolute requirements in a software project, is that
>this attitude cannot be permitted, and I could not have people with this
>attitude working on projects that I was managing.
>

I also would also work on a project where people are not held accountable for
their work. I've seen projects like these, every programmer hides behind the
"team" or the "group" name, no one is resposible for anything, no person
name is on any thing. a great place for laxy programmers to hide for
years in there. this is not for me.

>It's a matter of style, but I can certainly tell you that even though you
>can't really imagine that it works, my experience is that the "egoless"
>style in which people do not own the code they write, gives MUCH better
>results than the code ownership model -- you should try it some time!
>

egoless programming does not mean one should not "own" their work. 
you can have both togother. egoless means being open to others views, being
open to design changes, to changing your pakcage interface to accomedate new
design changes in other parts of the system, being open to describing to
others your work, being open to having code reviews and accepting positive
critic on your work. but one still "owns" the work they are working on !

I dont thing I can add more to this, I think I explained my views on this as
much as I can. at the end, every one is free to use the system they feel works
best for them.

Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<owning something DOES not mean that no one can look at each others work, it
just means programmers repsect each others work, and giving some feeling
of ownership to one's work will motivate programmers to improve their
work more, since their name on on their work going out of the door.

If my name is on a package, I am much more likely to try more to make
sure there is nothing wrong with it, if the department name is stamped on
every thing leaving that department, one is less likely to try to do the best,
since if something goes wrong, no one is responsible, it is the "department"
or the "group" that is resposible.
>>

Well it is certainly nice to have people illustrating what I am talking
about. This kind of "ego-centered" program (look at this it is mine!)" is
to me a very negative aspect, and a good software manager should try to
eliminate it.

It is absolutely NOT a necessary ingredient in motivation. It can be
replaced by "look at this, it is ours!" and I find that a MUCH more
constructive viewpoint.

I realize that there are all sorts of viewpoints here, but the above quote
from nabassi *exactly* represents the kind of thinking that I think can
be highly detrimental to high group productivity.

The big difference is that nabassi's view is that if names are not stamped
on each component then "no one is reponsible" [an exact quote, as you see].
My view of what you are aiming for is everyone feeling that everyone is
responsible. That's a much more constructive attitude.

The trouble with the "it's mine" viewpoint is that everyone concentratesw
too much on the part that is theirs, and not enough on the system as a
whole. The result is that some components will be fine, and other
components will be weak, and if you have a centered view that you won't
take responsibility for anything  except that which is "yours" [note
that this is an EXACT conclusion from the above paragraph], then there
is no one to take responsibility for the weak parts except the creator,
who quite likely was not well trained, or equipped, or capable of doing
the job right. In a group dynamic, people step in whereever they are
needed and take a group pride in what they create as a group.

Note that there is nothing new in what I am saying here, these are old
ideas. I did not invent the term "egoless programming"!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Paul Van Bellinghen]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

> If my name is on a package, I am much more likely to try more to make
> sure there is nothing wrong with it, if the department name is stamped on
> every thing leaving that department, one is less likely to try to do the best,
> since if something goes wrong, no one is responsible, it is the "department"
> or the "group" that is resposible.
>

I can tell you from experience that an engineer needs to have a circuit (HW
engineer) or a piece of code (SW engineer) that he/she feels that was created (and
maintained) by them in order to feel a sense of satisfaction in their contribution
to the project. I think that code reviews by piers (i.e. inspections) are a good
balance between communal development of code and private ownership.

Recall that we who live in a capitalistic system believe that private ownership
and competition result in a higher quality of products overall. This is proven by
a comparison with the products produced by socialistic/communistic systems of
government.

People need to feel a sense of pride in the goods and services they produce in
order for them to produce those goods and services to the best of their ability.
This directly translates into quality.

A good program development environment, including one based upon an
incremental/recursive build model, encourages individual participation in the
creation of the end program by allowing each individual to add his or her creative
"stamp" on the end program to the extent that each member of the team to feel a
sense of accomplishment in the code that they produced.

> It is absolutely NOT a necessary ingredient in motivation. It can be
> replaced by "look at this, it is ours!" and I find that a MUCH more
> constructive viewpoint.
>



[-- Attachment #2: Card for Paul  Van Bellinghen --]
[-- Type: text/x-vcard, Size: 332 bytes --]

begin:          vcard
fn:             Paul  Van Bellinghen
n:              Van Bellinghen;Paul 
org:            Lockheed Martin Fairchild
email;internet: pvanbell@mhv.net
title:          Staff Analyst
note:           WebPage: www.mhv.net/~pvanbell
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Paul says

  I can tell you from experience that an engineer needs to have a circuit (HW
  engineer) or a piece of code (SW engineer) that he/she feels that was
  created (and maintained) by them in order to feel a sense of satisfaction
  in their contribution to the project. I think that code reviews by piers
  (i.e. inspections) are a good balance between communal development of
  code and private ownership.

Careful here, you are just saying that in YOUR experience, YOU need to
have this feeling, but you are quite wrong to project this on all others.
So, if we take "an engineer" to mean you personally (and those who feel
as you do), fine, but not everyone needs or appreciates this personal
ownership.

  People need to feel a sense of pride in the goods and services they
  produce in order for them to produce those goods and services to the
  best of their ability This directly translates into quality.

Absolutely! But this can be a group sense of pride, and in my experience
the team spirit that comes from this is tremendously valuable. I think
you will find that people who have worked in this kind of cooperative
environment have found it very rewarding and productive.

After all, imagine if a sports team were entirely populated by people only
interested in what *they* could accomplish, as opposed to what the *team*
working together could accomplish.

One obvious disadvantage of the ownership model is that it makes it hard
to transfer things around. If you feel you own a piece of the system, then
you are not going to be happy turning it over to someone else, even if
such a transfer of responsbilities makes good sense from a team point of
view.

I realize that many, perhaps most, engineers reading this list simply
don't have the experience of working as part of a unified team. Too bad!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885398496@merv>, dewar@merv.cs.nyu.edu says...
>
>Paul says
>
>
>  People need to feel a sense of pride in the goods and services they
>  produce in order for them to produce those goods and services to the
>  best of their ability This directly translates into quality.
>
>Absolutely! But this can be a group sense of pride, and in my experience
>the team spirit that comes from this is tremendously valuable. I think
>you will find that people who have worked in this kind of cooperative
>environment have found it very rewarding and productive.
>
>After all, imagine if a sports team were entirely populated by people only
>interested in what *they* could accomplish, as opposed to what the *team*
>working together could accomplish.
>

but even in a sport team, each one is assigned responsibility for one part of
the field,
on a soccer team for example, (this is football for our outside the US viewers) 
you have someone in the center, someone in the front, and a goal keeper etc.. 
you do not see the goal keeper leaving his post and taking position on the 
middle field leaving his post open.  And also you do not have a player 
assigned to the front no willing to kick the ball away from his goal because 
the ball happened to be not in the region of the field he is assigned 
responsibility for.

you really can have people working together towards one thing and have 
individual responsibility and the healthy ownership that comes with it at the
same time.

>One obvious disadvantage of the ownership model is that it makes it hard
>to transfer things around. If you feel you own a piece of the system, then
>you are not going to be happy turning it over to someone else, even if
>such a transfer of responsbilities makes good sense from a team point of
>view.
>

Sure, I agree, but it is a normal human feeling for someone not to want to 
let go of something they have put allot of effort and improvement on. if 
you take care of your home, make improvements on it for long time, you 
become attached to it, and selling it will be hard even if it is what needs to
be done.

But the solution to this problem is NOT to prevent people from owning their own 
homes and instead have everyone live in community housing owned by 
the government, where it will then be easier to have people be moved 
from one part to another without having to worry about them having
developed any attachment to the place they "owned".

>I realize that many, perhaps most, engineers reading this list simply
>don't have the experience of working as part of a unified team. Too bad!
>

I can;t answer this one, since I have not asked every programmer reading
this how they feel about this issue. But I would like to think that 
many programmers like to help each others and work in a team and 
still being given their own tasks they can work on and they feel 
they are resposible for, even if it is a very small part of the 
the overall project.

Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<you really can have people working together towards one thing and have
individual responsibility and the healthy ownership that comes with it at the
>>

Yes, this can be achieved, where on earth did you say me see that it could
never be achieved. What I *did* say, from my experience with dozens of
different projects, is that all too often "ownership" is not at ALL
healthy. It is constantly a surprise to me to find out cases where a
large company has a big project and there are pieces of it that no one
knows and hence which cannot easily be modified. The reason in every case
is that the single person who owned and knew the code left the company,
and, as is the (rather odd) practice in the US, this was done with virtually
no warning, very abruptly (in France, and many other companies, the more
common practice is for the transition from one job to another to be less
frequent, and when it occurs, more gradual).

Yes, this can be avoided. All I am saying is that my preferred way of
avoiding this is to strive for the kind of model I have described. 

There is a lot written about these issues of team dynamics in software
projects, you might want to hit the literature!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

In article <dewar.885475413@merv>, dewar@merv.cs.nyu.edu says...

>What I *did* say, from my experience with dozens of
>different projects, is that all too often "ownership" is not at ALL
>healthy. It is constantly a surprise to me to find out cases where a
>large company has a big project and there are pieces of it that no one
>knows and hence which cannot easily be modified. 

well then Dr. Dewar, it seem then that you have been on a dozen 
projects where the management of those projects were bad and not 
organized and incompetent, so what is new?

A manager who does not know who is responsible and who currently working on
every piece of the system is a bad manager, do not fix this by the
drastic solution of having every one owning everything and no one owning
anything. Your solution to the problem seems to me worse than the 
problem itself.

>The reason in every case
>is that the single person who owned and knew the code left the company,
>and, as is the (rather odd) practice in the US, this was done with virtually
>no warning, very abruptly 

Again, you come up with a second problem which can be solved without 
abandoning the model of healthy ownership and the individual responsibility.

This is a management issue to make sure communication is always open 
between people while they are working of the project, regular 
design and discussion meeting between the members of the group so 
that people are more familiar with each others work, (I am all for
people being familar with each others work) and to ask for each 
programmer to have a well written document about his or her
work, so that when the programmer leaves (without giving the 
normal 2 weeks notice that they should do) the group is not left 
wondering what was that programmer working on and how to carry on afterwords.

So, you blamed lack of communications, little or no group meetings, 
no well defined means of communications between people, no documentation, 
etc.. on the ownership model, and you want to replace that with your 
model, hoping suddenly the management will wake up and that programmers
who did not communicate before will now start to and all will be fine.

>
>Yes, this can be avoided. All I am saying is that my preferred way of
>avoiding this is to strive for the kind of model I have described. 
>

All what I am saying is that your solution is to the wrong problem. The
problems you mentioned with the healthy ownership model (people 
leaving suddenly, people not knowing who is working on one part of 
the system) can be solved by fixing the management and by having 
more communications between people, and the other things I mentioned
above, these  things need to be done under any model.

regards,
Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[nabbasi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3119 bytes --]



Well, this is certainly is an interesting discussion.

I don't know why Dr. Dewar insists on making the 
point that if a programmer is made the ultimate one 
responsible for some task, then this implies the collapse 
of the team spirit and the immediate termination of
the cooperation between people working in the same project.

let me just give one simple example from real life, where 
people are assigned ownership of something, BUT still help 
each others.

When a patient enters a hospital he or she are assigned a doctor 
to take care of them. Lets assume for the sake of the example, 
that there are 2 doctors, one is Dr. A and the other is Dr. B in the 
same hospital, both are very qualified medical doctors.

Now Dr. A is responsible for their patient and assigned to take 
care of some specific patient,  the name of Dr. A is put on the top of
the chart of the patient so that every one knows who patient this is, and 
every one knows who is the Dr. in charge of  that patient and who to call
if something goes wrong with this patient.

It is Dr. A who is held accountable for something going wrong 
with his patient, notice I said �his patient� ,  I did not say  
�the ministry of health� patient,  or the �HMO� patient  or the 
�committee in charge of the hospital� patient.

Now, does this means that if Dr. B comes in one day when 
Dr. A was not on duty, and sees the patient of Dr. A in trouble, 
may be having some difficulty  breathing, or has falling off the bed 
and screaming for help, will Dr. B turn around and say "You are not 
my patient, so I will not help you, you are Dr.  A�s patient". ?? 

offcourse NOT!  Any doctor worth anything will jump in and help in the 
emergency, and so will many other Drs. available around. If Dr. B 
does not help because the patient is not his, then this is a bad Dr., it 
does not mean that the system of  assigning a patient to some specific
doctor was a bad idea.

Will Dr. B go and give some medicine to Dr. A�s patient because he 
thinks this new medicine is better what Dr. A has been giving the patient 
without first asking Dr. A? offcourse NOT !  this is something never 
heard of, just ask any medical doctor.  No Doctor will change or give new 
medicine to another doctor patient without first consulting the doctor 
in charge of the patient.

But according to Dr. Dewar style, each Dr. in the hospital should be free to
give any patient any medicine they think best,  because patients are all 
owned by the hospital or by the collection of the Drs. This is not only not  
practically, it is also dangerous, since not each Dr. can have the time to gain 
good knowledge of the conditions of each patient to give the correct 
medicine and the attention to give them the best individual care. 

Does this mean that Doctors do not discuses their patients with each others? 
offcourse they do, does this means doctors do not help each others, offcourse
they do.

Now, replace the patient above with an Ada package or a C++ class, 
and replace the medical doctor with software engineer,  and you 
will see what I mean.


Nasser

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

nabassi says

<<I don't know why Dr. Dewar insists on making the
point that if a programmer is made the ultimate one
responsible for some task, then this implies the collapse
of the team spirit and the immediate termination of
the cooperation between people working in the same project.
>>

There is a *world* of difference between a group of people cooperating
with one another, and a team. Of course no software project can possibly
succeed if people do not cooperate. And some team spirit must indeed be
there.

But it sounds like you have never really worked in a project where the
kind of ideals I propose are even approximated. That's clear from your
claim that it could not work. In fact, as people know who *have* worked
in this kind of environment, it *does* work, and it works extremely well.
I hope you get to experience this some time!

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <dewar.885243237@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Note that there is nothing new in what I am saying here, these are old
>ideas. I did not invent the term "egoless programming"!

Jerry Weinberg did, as discussed in The Psychology of Computer Programming. 
Jerry wrote that book while on a 2 month vacation in Italy.  In fact, he's
preparing an "anniversary edition" right now.

You can get the scoop about Jerry's activities at his website:

<http://www.geraldmweinberg.com/>

I just spent 7 days with Jerry at the Change Shop, in Sante Fe.  Highly
recommended!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Anonymous]

<884736089.2104295427@dejanews.com>
<199801191458.PAA28408@basement.replay.com>

On 19 Jan 1998 11:37:23 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

> [long discussion of regression testing at ACT]

Interesting information. Thanks for telling us about it.

This is an advantage to supporting a compiler; there are many
application areas where such a test suite would be difficult to create.
Presumably your customers are continually sending you candidates for
addition to this test suite.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Jeff said

<<This is an advantage to supporting a compiler; there are many
application areas where such a test suite would be difficult to create.
Presumably your customers are continually sending you candidates for
addition to this test suite.
>>

Absolutely! I commented in my message on this subject that I quite realize
this model is not easily adaptable for domains in which constructing a
comprehensive automated test suite is impractical.

Note that one of the big advantages of the public distribution model for
GNAT is that no only do our customers send us candidates for addition
to this test suite, but so do unsupported users. We get lots of bug
reports from unsupported users over the years, and whether or not they
turn out to be actual bugs or not, they have provided lots of interesting
test cases.

GNAT has been very extensively tested in this way for six years, and of
course everyone benefits from this testing, both supported and 
non-supported users.

RObert Dewar
Ada Core Technologies

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[James Hopper]

In article <dewar.885515552@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> It sounds like you are describing a badly mismanaged project. There is
> no doubt that team projects of the kind I describe require very careful
> management, and indeed are not easy to manage. I have seen this approach
> work well more than once. I also received a note from one programmer
> on some aerospace project who reacted that what I described was exactly
> what they did and that it worked very well.

Its unfortunate but this project has first rate people who can't seem
to mesh.  I agree is a management problem, but i also belive that its
made worse by this model.  I tend to belive that the egoless model
might make a first rate team better, but it can also, in my opinion,
make a team that hasnt gelled MUCH worse in many cases.  the question i
would ask as a manager is is the return worth the risk?  Its a case by
case call i expect

> 
> Note that in the GNAT project it is absolutely NOT the case that 
> everyone works on everything. That is hard to imagine as a model.
> The model is that there are no set limits on what people work on. 
> However, of course interest areas and expertise areas definitely
> develop, and in the case of GNAT, there will typically be 2-3
> people who know a given unit well, and are the most obvious people
> to work on it. However, when necessary people can definitely stray
> outside their area of primary expertise, especially when a simple
> fix or addition is involved.

> 
> The situation of no one being expert in anything is of course a scary one.
> My model is that people should be expert in a variety of things. You may
> also comment that this approach presumes very good people. That is true.
> I have always taken the viewpoint that a software project is better off
> with a smaller number of more competent programmers. The difficulty of
> managing N people for a given value of N is *certainly* not made easier
> by having less than fully competent people, if anything it is made
> harder, and the difficulty of managing N people climbs rapidly as N
> climbs.
> 

I think this is the crux of my difference with you robert.  I would
probably agree that a team is composed of smaller subgroups who
specialize (as oposed to own) an area of the problem domain.  Your
description up to now kind of gave me the impression that you were
advocating anyone could at any time work on anything, if no one owns it
than no one controls it i guess is my thinking.  I admit that could be
my own pre-concieved notions at work.  If this type of subgroups is
what you are talking about then i think we can agree, as thats closer
to my groups method of operation.  

Oh and since some of the SAIC folks do read this group let me hasten to
mention that the folks i work with at SAIC are everybit as first rate
as anyone elses 

;-)  We have a really great group of folks who work very well togeather
as a team for a very long time on our Radar simulation product line.


> But still, remember that the original motivation of this thread was the
> discussion of the value of absolutely consistent coding standards. This
> is an easy-to-achieve first step towards being able to work better as
> a team, and is something that, with competent programmers who recognize
> the value of consistency of style, is easily achieved.

Yes, one of the things i enjoy about working with the radar team at
SAIC is its one of the very few groups i work with where i can read and
modify the code and not want to start reformatting/rewritting it. We
have worked togeather and learned togeather so long that our styles
mesh very well, at least from my point of view.  i can usually tell
differences in style when working with other groups, this group its
rare that i feel this.  Let me add that working with the gnat code is a
similar experience in that its all pretty much one style its just that
its different from the style i use most of the time.  But i have
learned to adjust when working with gnat code.  Of course the style
checks in the compiler help that a lot ;-)

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[James Hopper]

In article <dewar.885475174@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> But it sounds like you have never really worked in a project where the
> kind of ideals I propose are even approximated. That's clear from your
> claim that it could not work. In fact, as people know who *have* worked
> in this kind of environment, it *does* work, and it works extremely well.
> I hope you get to experience this some time!

Robert,

Well i have, and my experience is that the ONLY place i saw it work is
the GNAT team.  It works very well at ACT in fact, but you have a very
atypical bunch of folks to work with.  The ACT folks are all at the top
of the curve for their respective levels of experience.  I am in fact
doing a kind of audit for a large software project in the avionics
domain where this approch is one of the primary reasons this project is
in so much trouble.  yes everyone works on everything, but the other
side of the coin is no one is really expert in anything.  everyone is
constantly doing a learning curve!  i agree with your point that there
are projects where only a single person can modify key pieces of code,
i have been there as well.  Thats why the folks i work with do
walkthroughs, read each others code to learn new techniques etc. there
is a middle ground between the two extremes.  What is important is for
people to be pragmatic and blend both approches!

jim

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

<<Well i have, and my experience is that the ONLY place i saw it work is
the GNAT team.  It works very well at ACT in fact, but you have a very
atypical bunch of folks to work with.  The ACT folks are all at the top
of the curve for their respective levels of experience.  I am in fact
doing a kind of audit for a large software project in the avionics
domain where this approch is one of the primary reasons this project is
in so much trouble.  yes everyone works on everything, but the other
side of the coin is no one is really expert in anything.  everyone is
constantly doing a learning curve!  i agree with your point that there
are projects where only a single person can modify key pieces of code,
i have been there as well.  Thats why the folks i work with do
walkthroughs, read each others code to learn new techniques etc. there
is a middle ground between the two extremes.  What is important is for
people to be pragmatic and blend both approches!
>>

It sounds like you are describing a badly mismanaged project. There is
no doubt that team projects of the kind I describe require very careful
management, and indeed are not easy to manage. I have seen this approach
work well more than once. I also received a note from one programmer
on some aerospace project who reacted that what I described was exactly
what they did and that it worked very well.

Note that in the GNAT project it is absolutely NOT the case that 
everyone works on everything. That is hard to imagine as a model.
The model is that there are no set limits on what people work on. 
However, of course interest areas and expertise areas definitely
develop, and in the case of GNAT, there will typically be 2-3
people who know a given unit well, and are the most obvious people
to work on it. However, when necessary people can definitely stray
outside their area of primary expertise, especially when a simple
fix or addition is involved.

The situation of no one being expert in anything is of course a scary one.
My model is that people should be expert in a variety of things. You may
also comment that this approach presumes very good people. That is true.
I have always taken the viewpoint that a software project is better off
with a smaller number of more competent programmers. The difficulty of
managing N people for a given value of N is *certainly* not made easier
by having less than fully competent people, if anything it is made
harder, and the difficulty of managing N people climbs rapidly as N
climbs.

Other things being equal, i.e. in particular the ability to get the job
done, the fewer people working on a project the better.

I don't for a moment present my model as something that can be achieved
in all circumstances, indeed in most project environments there are a
sufficient number of people committed to the personal ownership model
that imposing something different may be extremely hard, especially if
there is no one who can effectively dictate how things will be done.

But still, remember that the original motivation of this thread was the
discussion of the value of absolutely consistent coding standards. This
is an easy-to-achieve first step towards being able to work better as
a team, and is something that, with competent programmers who recognize
the value of consistency of style, is easily achieved.

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Richard Kenner]

In article <6a8vgd$cr7@nntp1.erinet.com> jhopper@erinet.com (James Hopper) writes:
>I think this is the crux of my difference with you robert.  I would
>probably agree that a team is composed of smaller subgroups who
>specialize (as oposed to own) an area of the problem domain.  Your
>description up to now kind of gave me the impression that you were
>advocating anyone could at any time work on anything, if no one owns it
>than no one controls it i guess is my thinking.  

The key here is *could*: "could work on anything".  That does not mean
that, in practice, people in fact *do* work on anything.  I'm probably
the most specificialized person in the GNAT team: I work on GCC and
the interface between the GNAT front end and GCC (Gigi). I don't know
the front end (or even the Ada language) very well.

Many bugs initially go to me, since it's Gigi that complains about
errors in the tree generated by the front end.  My normal procedure is
to "interpret" the complaint and let people more familiar with the
front end fix it.  But once in a while if it looks like a simple fix
and I feel comfortable doing it, I'll fix the bug in the front end.

As another example, we recently added a new validity test in Gigi and
found that a large number of our regression tests produced trees that
were now "invalid".  These all represented bugs in the front end, but
since I was, at that moment, one of the people most familiar with the
issue, I fixed these myself, even though it meant a couple of dozen
changes in front end files, which I don't normally touch.

The point is that, in doing these things, I didn't need anybody's
"permission" or have to be at all concerned that somebody would be at
all upset that I did these things.  In each case, everybody was
pleased they didn't have to do this.

All that was required was for me to feel that I had sufficient comfort
with the code I changed to do so cleanly, and that all the regression
tests passed.

As Robert said, this sort of thing wont't work for everybody, but the
main skill needed is the experience to know what you and don't know.
This, however, is a nearly essential skill in technical work anyway,
for both managers and engineers.

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

<<I think this is the crux of my difference with you robert.  I would
probably agree that a team is composed of smaller subgroups who
specialize (as oposed to own) an area of the problem domain.  Your
description up to now kind of gave me the impression that you were
advocating anyone could at any time work on anything, if no one owns it
than no one controls it i guess is my thinking.  I admit that could be
my own pre-concieved notions at work.  If this type of subgroups is
what you are talking about then i think we can agree, as thats closer
to my groups method of operation.
>>

No, you are looking for more structure than is desirable when things are
working in the most effective manner. In the GNAT project it is most
definitely the case that anyone at any time *can* work on anything. 
Naturally people do NOT work on things on which they are not sufficiently
expert. People have to know what they can do and what they can't do.
In the case that went astray, sounds like this important principle is
not being followed (indeed cannot be followed if no one is an expert
on anything, as you claimed).

There is a big difference between a situation in which there is a 
structured mandate on who works on what, and one in which there is
natural specialization based on skills.

I don't see any disagreement however between us. I am merely saying
that the model I propose can work well. I certainly have a disagreement
with nabassi, whose strenuous defence of the principle that it is
impossible to avoid ownership principles, or rather that lack of
ownership and quality are incompatible. However, you yourself note
that the GNAT project works well in this mode.

You give an example where it doesn't work. So what? I definitely agree
that the model I give does not work in its most extreme form in all
cases. Some of the ingrediants we have discussed are:

  o you need some very good regression testing so that people making
	changes do not cause problems. This is useful anyway, but
	particularly important in a shared-work environment. No one
	should get annoyed if someone else helps work on anything,
	quite the contrary in fact, but it is upsetting if the system
	keeps breaking because someone else has changed things. Note
	that in the GNAT case, there is only one set of sources which
	we all share, people do not create personal variations except
	on a very temporary basis for testing the latest fixes.

  o you therefore must have a project where it is possible to create
	such tests and automate their use.

  o you need an excellent group of people who knows what they can and
	cannot do.

  o you need to make sure that the whole operation is carefully setup
	and managed so that it works.

Many software projects go bad for many reasons. Bad process is certainly
often a reason. More often *no* process is the reason!

But once again, go back to the origin of this thread. Which was the issue
of consistent coding standards.

Depending on the circumstnaces, the amount of shared work that can be
successfully achieved will vary. But even in a strenuous ownership
environment, how can it possibly help to have gratuitious variations
in style? Such differences in style will make code walkthroughs harder,
and will discourage people from reading one another's code let alone
changing it.

The only argument put forward in favor of allowing relaxed style is one
(I think from Michael Brenner, but I may misattribute) that says "You
need to let programmers do their own thing, or they will get frustrated"
or something like that.

TO me this is not just a *weak* argument, it is a counter-argument. It
shows EXACTLY why it is important to have strenuous coding standards
on a project. Such standards are needed to firmly stamp out this kind
of destructive individualism. I think individual accomplishment is
important, and in any team, even one working in a highly cooperative
manner, people must be aware of and respect the contributions of
individuals and their knowledge. But if people have to resort to
idiosyncratic coding styles to put their "stamp" on things, that is
a wholly negative effect in my view.

Note that the idea of strenuous coding standards is nothing new. I have
been involved with a number of large scale IS projects using COBOL, and
I never saw a COBOL shop which did not have a published set of detailed
coding standards, and this is for a language that is MUCH more structured
than Ada in the first place. One of the consequences is that style in
COBOL tends to be much more disciplined, and the phenomenon of a big
project with a consistent style is much more common.

I think part of the trouble is that the Ada tradition at least partly
comes out of the valiant-lone-hacker past, as opposes to the disciplined
engineer past, and that is why we have a fair number of cowboys
(and cowgirls!) who are determined to do their own thing in a highly
individual manner. 

I think this needs to be throttled when it is encountered!

Robert

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Paul Van Bellinghen]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

> I have always taken the viewpoint that a software project is better off
> with a smaller number of more competent programmers. The difficulty of
> managing N people for a given value of N is *certainly* not made easier
> by having less than fully competent people, if anything it is made
> harder, and the difficulty of managing N people climbs rapidly as N
> climbs.

I have also found this to be the case in every large project I have been on.
The project starts out with a small number of quality software engineers who
layout the top level design implementation based on the requirements. They
also set up program and documentation standards (we have always used a
real-time structured analysis approach).

The project then "staffs-up" with anyone they can get their hands on to do
the bulk of the coding. Unfortunately, the group is too big and higher
priority demands too numerous for the program leads to keep track of whether
these people are adhering to the standards set up. These people supposedly do
low level code testing.

With the bulk of the code written, the project staffs back down to the same
people it started with who are left to get the system software working
together. Unfortunately, much of the code is not written well, having bugs
and inefficiencies.

The point is that we would have done better staying with the 8 or 10 people
we started with - even if it meant taking a few extra months at the code
phase.



[-- Attachment #2: Card for Paul  Van Bellinghen --]
[-- Type: text/x-vcard, Size: 332 bytes --]

begin:          vcard
fn:             Paul  Van Bellinghen
n:              Van Bellinghen;Paul 
org:            Lockheed Martin Fairchild
email;internet: pvanbell@mhv.net
title:          Staff Analyst
note:           WebPage: www.mhv.net/~pvanbell
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Paul says

<<The project then "staffs-up" with anyone they can get their hands on to do
the bulk of the coding. Unfortunately, the group is too big and higher
priority demands too numerous for the program leads to keep track of whether
these people are adhering to the standards set up. These people supposedly do
low level code testing.
>>

The phenomenon where adding people to a project actually decreases
overall productivity is a well known (and well studied) one.

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[James Hopper]

In article <dewar.885555487@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> You give an example where it doesn't work. So what? I definitely agree
> that the model I give does not work in its most extreme form in all
> cases. Some of the ingrediants we have discussed are:

actually i only elaborated on the most recent problem project i have
seen, i have seen it tried in several projects.  but i have come to
understand that what i saw was bad implementations of this system.

But i think where i was not thinking totally clearly about this for my
own objectsions is that i belive a task started from scratch should be
partitioned into work packets and the work packet largely belongs to a
small group or a person until its through unit test when its integrated
into the larger system it becomes community property and i agree our
folks treat that pretty much like the gnat team. We don't think twice
about fixing whatever during integration depending only on our ability
to get it done right as richard claims.  I guess what i am saying is i
think i understand your position better now and as you say i don't
think we differ by much if anything on this issue robert at least for
my own team, but i have seen a lot of teams who are NOT capable of this
ACT and trying to force it on them is a recipe for disaster.  You need
assess your people as a manager before deciding on how this is going to
work before starting, and not just your people the managers are
probably more critical to the success of this than the people.

jim

Re: Distinguishing type names from other identifiers

[Philip Brashear]

In article <69nt40$q7n@top.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>   > ... everyone should agree ...
>
>Dr. Dewar, it is obvious that EVERYONE does not agree with you that

Ahem!  Actually "EVERYONE does not agree with [Robert Dewar]" is a
false statement, since there are people who do agree with him.
Perhaps Michael meant "NOT everyone agrees with [Robert Dewar]".

One might take this as an example of attention to readability,
I suppose.

(:-)

Phil Brashear

Re: Distinguishing type names from other identifiers

[Benoit Jauvin-Girard]

On 16 Jan 1998, Robert Dewar wrote:
[SNIP - In reply to Michael] 
> Now here I disagree. If you have programmers (I don't care whether they
> are maintaining code or building it), and their orientation is that they
> react to quality standards by deciding that it means they cannot write
> cool code, and they want to do their own thing, then the one and only
> preferable solution is to get rid of these programmers. What you refer
> to as regimentation is something that quality workers in all fields
> must learn to accept. Yes, I realize that the programming field tends
> to be full of mavericks who insist on writing neat cool code, but this
> is a signal weakness of the field, not a strength.
> 
> In practice I find one of the advantages of Ada is that Ada tends to
> encourage what you would like to call "regimented" environments, and 
> thus to scare off the "cool neat code" crowd. 

A small interjection: while I cannot truly disagree with the main idea
above (nobody likes indecipherable "Joe code", especially after Joe has
left the company), I find it worrysome that you'd call something that
scares programmers away from Ada an 'advantage'.  Isn't one more
programmer choosing to work in Ada a good thing for the community?

..And I can only hope you don't mean that Ada makes it impossible to write
neat, cool code!  (Since it's patently untrue.)

--
... Benoit Jauvin-Girard (jhove@cam.org)

Re: Distinguishing type names from other identifiers

[Robert Dewar]

BJG says

<<A small interjection: while I cannot truly disagree with the main idea
above (nobody likes indecipherable "Joe code", especially after Joe has
left the company), I find it worrysome that you'd call something that
scares programmers away from Ada an 'advantage'.  Isn't one more
programmer choosing to work in Ada a good thing for the community?

..And I can only hope you don't mean that Ada makes it impossible to write
neat, cool code!  (Since it's patently untrue.)
>>

Well of course it is possible to display the neat/cool phenomenon in any
language. Unfortunately we don't know how to design languages that only
permit straightforward easy to understand code. I said discourage and
not prohibit :-)

As for scaring away undisciplined programmers -- if that happens, and I
think in fact it does, then no aplogies, this is a GOOD THING :-)

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Anonymous]

<69lael$90o@top.mitre.org>
<01bd2207$18f3fac0$95fc82c1@xhv46.dial.pipex.com> <dewar.884945034@merv>
<69nt40$q7n@top.mitre.org> <dewar.884996184@merv>
<Pine.BSF.3.96.980116171810.3901B-100000@shell5.ba.best.com>
<69rnvv$gjr@drn.zippo.com> <dewar.885126007@merv>
<69t6fe$brl@drn.zippo.com>

On 18 Jan 1998 17:47:44 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

> nabassi says
> 
> <<well, having 2 or more programmers working on the same peice code
> could not work well. It is like having 2 cooks making the same
> meal. or 2 or more painters drawing on the same picture at the same time.
> 
> I for one, could not work on a package or class, where
> I came in the morning to see my code has been modifed, and I could
> never modify someone else code on the project without a very good
> reason (customer on the phone screeming, the owner of the package is out
> sick, etc..) and without at least asking first if at all possible.
> 
> I am all for the team spirit and the little community feeling, but
> I beleive that each programmer should be assigned a task, and they
> own up to it, and they are resposible for it and no one else.
> >>
> 
> OK, there it is, both negative aspects of code ownership! 
> 
> In case my position is not clear, I regard both viewpoints as unfortunate
> in the quest to maintain maximum code quality and productivity. In
> particular, if you have this level of code-ownership viewpoints, you
> will very seldom get people reading other people's code in a routine
> manner. It is this many-eyes-on-the-code phenomenon which is valuable
> for code quality. Also, if there is this much code ownership going
> on, then you are bound to get divergence in style, further contributing
> to people being unwilling to look at, let alone work on, other people's
> code.
> 
> I quite understand that a lot of programmers feel as nabassi does, but
> for me, one of my absolute requirements in a software project, is that
> this attitude cannot be permitted, and I could not have people with this
> attitude working on projects that I was managing.
> 
> It's a matter of style, but I can certainly tell you that even though you
> can't really imagine that it works, my experience is that the "egoless"
> style in which people do not own the code they write, gives MUCH better
> results than the code ownership model -- you should try it some time!
> 
> Robert Dewar
> 
> 
> 

We're missing something here from both viewpoints: inspections! If I'm
working on any meaningful piece of software, I want feedback from others
before I do anything significant. Whether I'm doing the original design
or a significant modification of a package, I want and should be
required to obtain feedback on the proposed design or modification, and
on the actual implementation that I do. After all, I know I make errors;
as a software engineer, I probably spend more time dealing with errors
than original development.

So, if I'm working on a package, I would not expect to come in one
morning and find an unexpected modification. I would know about any
modification in advance. Similarly, if I'm modifying a package, I would
want the original designer involved in inspecting my proposed
modifications, so he would not come in and find an unexpected
modification.

Of course, if I'm absent for an extended period (more than a couple of
days), I would expect to find modifications to what I've been working
on.

I doubt if this is foreign to either Robert Dewar or nabassi (Nasser).
This inclusion in the discussion of any modification is probably what
nabassi (Nasser) means by not touching a package without contacting the
original designer, if possible, and probably what Robert Dewar means by
everyone knowing about everything.

Correct me if I am wrong.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"English bed-wetting types."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Jeff Carter said

<<So, if I'm working on a package, I would not expect to come in one
morning and find an unexpected modification. I would know about any
modification in advance. Similarly, if I'm modifying a package, I would
want the original designer involved in inspecting my proposed
modifications, so he would not come in and find an unexpected
modification.

Of course, if I'm absent for an extended period (more than a couple of
days), I would expect to find modifications to what I've been working
on.

I doubt if this is foreign to either Robert Dewar or nabassi (Nasser).
This inclusion in the discussion of any modification is probably what
nabassi (Nasser) means by not touching a package without contacting the
original designer, if possible, and probably what Robert Dewar means by
everyone knowing about everything.
>>

Actually this would be foreign to me. Sure major changes do get discussed
in advance, but for minor fixes, and even significant additions, we use
entirely another scheme, which is to rely on a very extensive regression
suite (several million lines of code, in 25,000 files in 4,500 directories).

No one is allowed to make any changes without running this suite on their
changes and making sure that no regressions are caused.

We have found this suite MUCH more effective than another pair of eyes,
though another pair of eyes is always valuable for dealing with issues
other than functional correctness (e.g. efficiency and style).

There are two factors in the GNAT project which are relevant here:

1. We often need to fix problems for customers with a critical problem
in a very short time scale, while retaining quality control. Requiring
review cycles and discussions of any modification would be inconsistent
with the required rapid turn around time.

2. Compilers are a very nice case for testing. It is possible to build
very effective test suites (we use our own internal test suite I referred
to before, the ACVC test suite, and the DEC test suite, and between them
we have found them very reliable in avoiding mistakes in changes)

Of course we get MANY false attempts that do NOT get through the mailserver
(I don't know what percentage of mail server attempts, i.e. attempts ot
run our regression suite, fail, but it is high, I would guess 75%. It is
amazing how often a change that looks completely correct, and which any
additional pair of eyes would agree is correct, is wrong because of some
subtle interaction caught by some weird test in the suite!)

The way our mail server works is that you prepare your change as a patch,
and then send it to a special mailserver address, choosing which of several
machines to run on (normally any old machine will do, but sometimes if
you are making a change that might be machine dependent, you can run it
on a particular machine, or perhaps even more than one machine). Then
a few hours later you get a report, and you can't check things in unless
the report is clean

THen as a backup to this process, a message goes out to the group noting
the revision history of the change that has been made, and anyone who
usefully can will check the change to make sure it makes sense. Furthermore
than night the regression suite will be rerun (which catches the very rare
cases of conflicting changes -- we have not seen one of these in recent
memory, certainly not for a year), and also the ACVC and selected DEC
test suite tests are run.

We have found that this scheme works very well for us. Obviously it is
not necessarily applicable to other environments. In particular it is
often very difficult to construct a reliable test suite for many
applications.

Robert Dewar
Ada Core Technologies

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Marc Wachowitz]

<rant apology=no>

Paul Van Bellinghen <pvanbell@mhv.net> wrote:
> I can tell you from experience that an engineer needs to have a circuit
> (HW engineer) or a piece of code (SW engineer) that he/she feels that was
> created (and maintained) by them in order to feel a sense of satisfaction
> in their contribution to the project.

It may be true for your own experiences so far, and for the experiences
so far of quite a few other people, but it isn't always true (and it might
even some day cease to be true for you, one never knows ;-). For example,
for me, both the most satisfying and the most effective motivation wrt. to
quality of the result is interest in the process itself (referring to the
social as well as technical factors) and in the product - at least beyond
a point where some very basic material requirements for living are met.
Of course there are necessary partial tasks which hardly anyone will enjoy
performing, but the intelligent reaction is to find ways to reduce them, as
far as direct involvement of humans is concerned (as someone said, program
development is intelligent laziness), and not to hand it down to unfortunate
losers in an insane form of competition, which is inhumane (and does waste
a lot of human potentials, too).

> Recall that we who live in a capitalistic system believe that private
> ownership and competition result in a higher quality of products overall.
> This is proven by a comparison with the products produced by socialistic/
> communistic systems of government.

<social-philosophy>
Clearly, there's a tendency towards "product ownership" - whether by a group
or by an individual - built into the current social/economical structure, but
that doesn't at all mean that I'd like it. I don't like it, but it does take
more than a few people to change this setup. I do carefully look at the subtle
influences this environment does have on mentality, and try not to let it take
root there, even though in many cases - far beyond the range of some obvious,
isolated decisions - it's hard to avoid following these patterns; that doesn't
preclude a critical view about this. As far as the supposed "success" alluded
to above is concerned, it's only true wrt. the popular confused usage of those
notions. So-called "socialistic" countries effetively had a more government-
(or state)-oriented capitalism, opposed to a more market-oriented capitalism,
which are both variations of the same fundamental structures, which are both
subject to Marx' Critique of Political Economy, and the more recent continued
development of Critical Theory (advanced by philosophers like Max Horkheimer
or Theodor W. Adorno). There's no need to be fooled by those countries' silly
propaganda pretending to have anything but cliches common with the notion of
communism, which would have to be a movement overthrowing this mess, a free
association of free individuals, which cannot be based on oppression.
</social-philosophy>

> People need to feel a sense of pride in the goods and services they produce
> in order for them to produce those goods and services to the best of their
> ability. This directly translates into quality.

<psychology>
Why make a detour via pride, with all its negative baggage, and not work
towards a social structure and climate where joy is derived from what's
actually going on, and can be shared with other humans without all those
pointless fights for (psychical or material) "territory"? Let's say you're
enjoying a beautiful sunset, something in which you'd hardly take pride,
and someone else is also enjoying it. Does their joy reduce your joy? I'd
guess it doesn't, and likewise, I don't see why pride should be somehow
positive. If humans appear to need to add pride to find joy, what does
that tell us about an environment which puts forth those conditions? The
human mind doesn't exist independent from the society by which it is formed
and which it is forming. Personally, I'd rather reduce such attachment; it
looks like it's no more conductive to happiness than a drug addiction would
be - just while one is addicted, one may believe that it would truly bring
enjoyment, and rationalize the suffering that comes with it.
</psychology>

</rant>

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[TConiam]

>My own personality is most comfortable with the egoless style, and
>that's how I prefer to do things.  So I mostly agree with Robert here.

So do I, although it is at some times a very hard personal internal battle when
it comes to having someone else find faults or bad assumptions in the code I've
created.  However, once all is laid out on the table I learn from it and try to
avoid the same mistakes.  I also never blame the individual who found the
fault, in fact I let them know that I appreciate their insight.

>
>Example: I'm working on a certain package, and I decide that one of the
>exported procedures is poorly named, so I want to change the name.  It
>seems to me that the best thing is for me to do a global search and
>replace, and change all the call sites (assuming the source control
>system doesn't lock me out of some file).  But I've worked with some
>people who are annoyed at that.  They prefer that I send them e-mail,
>saying "I've changed XYZZY to Do_Good_Stuff, please fix the call sites
>in 'your' code."  To me, that seems inefficient, and disruptive, since
>it leaves things in an inconsistent state.  In fact, it might well cause
>me to decide that the change is too costly, and leave the bad identifier
>alone, thus damaging the long-term quality of the code.
>

In this situation we have always brought the group together and had a short
discussion about the global change.  If the group agrees, it is assigned to one
person to accomplish, generally the one suggesting the change, this assures
consistancy and responsibility for it's accomplishment.  If the group feels it
is not necessary, it is not done, this prevents unecessary or arbitrary
changes.

Todd Coniam

Re: who owns the code? was Re: Distinguishing type names from other identifiers

[Robert Dewar]

Todd says

<<So do I, although it is at some times a very hard personal internal battle when
it comes to having someone else find faults or bad assumptions in the code I've
created.  However, once all is laid out on the table I learn from it and try to
avoid the same mistakes.  I also never blame the individual who found the
fault, in fact I let them know that I appreciate their insight.
>>

for me, things are quite different. If I make a stupid or not-so-stupid
error in my code, and someone else finds it (and preferably fixes it),
my only reaction is to thank that person for helping to improve the
code -- basically the point is that it is *not* an error in *my* code
at all, it is an error in *our* code, and it is completely irrelevant
who put it there, what is important is for *us* to fix it.

Robert

Note: I realize that to achieve this requires a group of people all of
whom are self-confident, and respect one anothers work. But that's a good
goal anyway for any group effort.