Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!sri-unix!husc6!cca!g-rh From: g-rh@cca.CCA.COM (Richard Harter) Newsgroups: comp.software-eng Subject: Re: Coordinating Software Development (long) Message-ID: <23868@cca.CCA.COM> Date: 2 Feb 88 12:05:10 GMT References: <2457@orca.TEK.COM> <1713@ttidca.TTI.COM> <1315@vaxb.calgary.UUCP> <1664@desint.UUCP> Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter) Organization: Computer Corp. of America, Cambridge, MA Lines: 65 Keywords: configuration management, sccs, project control, RCS In article <1664@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >In article <1315@vaxb.calgary.UUCP> jonesb@calgary.UUCP (Bill Jones) writes: > >> Okay, suppose your company is working on the next release of a product >> already in the field. An important customer reports a critical bug, >> ... >> >> Parallel development paths may have the danger of conflict, but proper >> management and tool support can minimize it. I would be interested in >> hearing of any non-parallel system which cleanly supports both new >> development and maintenance of past releases. Although an adequate tool set is critical, the most important factor is proper management. I can speak to this from some experience since SMDS is in the business -- our product is a software management system and our customers are software managers and CM people in companies of a variety of sizes -- and we get to see what works and doesn't work. What happens in most organizations is that development happens first, an ad hoc system is worked out by the developers, CM, QA, and customer support get tacked on as an after thought, and things get rather messy after a while. Once things get sufficiently entrenched it becomes very hard to restore order. I don't want to go into a lot of detail, but I will make two observations. (1) Once you have an existing organization, there is a political problem. (2) Good CM and QA require organizational commitment; they are not an add on. As to parallel development -- "new development and maintenance of past releases" is inherently parallel. Actually "parallel" is a misleading term. It suggests independent paths of equal priority. What really goes on is that one has a mainline product(s) with variants. The variants may be enduring (separate supportable releases) or transient (development efforts). What one tries to do is, so to speak, minimize the distance between variants and the mainline. From the developers perspective, however, the process is linear. The developer ordinarily is working with a single variant that is evolving over time. Going back to previous versions, and merging changes are useful, but not essential. Development is implicitly constrained by the need to keep the distance between the variant and the mainline small. A lot of 'good software practice' is really an expression of this requirement. > >RCS supports this very nicely; you simply create a branch for the bug fix >while development continues on the main path. RCS even provides the "-j" >switch (admittedly a very hard switch to use correctly) to help you merge >that fix back into the main branch later. (You can also use System V's >sdiff program, or Larry Wall's patch program, to achieve similar results). > >I believe you can also do this with SCCS, though I haven't personally >created an SCCS branch while another revision was actually checked out. One should, of course, understand that a tool for merging is not the same thing as successfully merging. Merging, at the mechanical level, is not terribly difficult. The real problem is that the merged software is neither fish nor fowl; there is an interaction between the two lines that were merged that is not present in either parent line. Ideally one creates lines that are orthogonal; i.e. the changes in line A are independent of the changes in line B. Arranging orthogonality is a part of good software management. In practice complete orthoganality cannot be ensured, and the merge process must take this into account. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.