mjl@cs.rit.edu (11/14/89)
mcilree@mrsvr.UUCP (Robert McIlree) writes: >Finally, how many of you out there in the commercial world always >work on new, start-completely-from-scratch, projects? I, in 7 >years, have worked on 2 of this type (out of over 15 total). The >rest were either extensions to existing systems, integration work, >or derivatives of existing systems converted to different applications >(reuse). Thus, the ability to read and comprehend anothers code is >critical, and should really come first before trying a start-from- >scratch project. and rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In these MCCR systems, most of the >'maintenance' effort is devoted to enhancing these long-lived systems, not >in removing design or production errors or in restoring the product to its >original performance. This reflects my experience as well: few of the systems I've ever worked on were developed "from scratch." For better or worse (unfortunately, all too often the latter), the teams I've been on had to modify an existing system, under the constraints of that system's original design. Most recently I was on a project to convert 60 K lines of stand-alone DG assembler to C under Unix. The constraints were such that the "new" system embodies all the design decisions, good and bad, made 15 years ago. In spite of this, little attention seems to be paid to the issues surrounding the evolution of software systems (other than Belady & Lehman's "Program Evolution: Processes of Software Change" Academic Press, 1985). I was at the last ICSE in Pittsburgh, and was disappointed that little attention was paid to these problems. Indeed, I sat in on a BOF on "Problems of Large System Development" with a friend of mine from a regional phone company, but when we tried to bring up this issue, the response we got was "convince your company to rewrite it." (Thanks a heap!). As most of the participants were from aerospace firms, I was left with the distinctly uncomfortable feeling that in their world the goal was to finish the current product with minimum fuss, and to Hell with evolution. After all, they might not get the follow-on contract from DoD. My "real world" is that of software engineering for embedded systems in commercial products (This is similar to that of my friend at the phone company). In this "real world," software is subject to demands for continuous change without major redesign. Unless we can find ways to get the original design right (that is, so it can evolve), we'll continue to be stuck to these tar babies of our own creation. Mike Lutz Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu