From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2afac1a4161c7f35 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: who owns the code? was Re: Distinguishing type names from other identifiers Date: 1998/01/23 Message-ID: X-Deja-AN: 318582098 References: <01bd2207$18f3fac0$95fc82c1@xhv46.dial.pipex.com> <69nt40$q7n@top.mitre.org> <69rnvv$ <6a8mir$caa@nn X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 885556474 3112 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-01-23T00:00:00+00:00 List-Id: <> 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