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

[dewar@merv.cs.nyu.edu (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