se90wak@cc.brunel.ac.uk (Wael A Khalil) (06/05/91)
I would like to initiate a discussion on maintainability! there are two main positions that people (and literature) take on how to produce miantainable (and modifiable) software: - Adopting a software development method and making sure that the documentation is up to date will insure that the software will be highly modifiable. - Software engineering method is not enough, there is more to it. what do you think? I also would like to make it clear that it is not Maintenance I'm talking about it is enhancements, further development and re-engineering activities.
jls@netcom.COM (Jim Showalter) (06/06/91)
>I would like to initiate a discussion on maintainability! >there are two main positions that people (and literature) take on how to >produce miantainable (and modifiable) software: > - Adopting a software development method and making sure that the > documentation is up to date will insure that the software will > be highly modifiable. If one adopts a software development method that is worth anything, then one should wind up, as a consequence, with software that is maintainable and modifiable. Another way to put this is that one of the criteria for selecting a software development method is that the method, properly applied, should result in software that is maintainable and modifiable. The question then becomes: are there software development methods that result in maintainable and modifiable software and, if so, what are they? This question, I answer with a resounding yes: a method that stresses architecture and design, rapid prototyping, iterative development, incremental delivery of functionality and documentation, abstraction, and all the other stuff that has been discussed in this group is such a method. I've seen such a method followed in real life on real projects of significant scope and complexity, and I've seen highly maintainable and modifiable software result from it. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
fwb@pollux.tmc.edu (Fred Brehm) (06/06/91)
>>I would like to initiate a discussion on maintainability! >>there are two main positions that people (and literature) take on how to >>produce miantainable (and modifiable) software: >> - Adopting a software development method and making sure that the >> documentation is up to date will insure that the software will >> be highly modifiable. > >If one adopts a software development method that is worth anything, then >one should wind up, as a consequence, with software that is maintainable >and modifiable. Another way to put this is that one of the criteria for >selecting a software development method is that the method, properly >applied, should result in software that is maintainable and modifiable. Don't you think the design of the software (or the whole system, only partly software) has something to do with it too? Will "a software development method that is worth anything" be so powerful that it will provide the crystal ball to predict all future modification requests? Perhaps there are some kinds of modifications that will not be possible, or be extremely hard, for a given system architecture. Fred -- Frederic W. Brehm Siemens Corporate Research Princeton, NJ fwb@demon.siemens.com -or- ...!princeton!siemens!demon!fwb
se90wak@cc.brunel.ac.uk (Wael A Khalil) (06/06/91)
In article <1991Jun5.201807.13286@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >..... >The question then becomes: are there software development methods that >result in maintainable and modifiable software ....I've seen >such a method followed in real life on real projects of significant scope >and complexity, and I've seen highly maintainable and modifiable software >result from it. I would like to learn more about such methodology, and if you (or any one else can point out those methodologies, are they used in industry, what kind of application? The neture of the development infra-structure? Are there none-Object Oriented methods. What is the minimum support needed form the development environment/programming language. And that leads me to enquire about Object Oriented methods that are used in practice and about practical experience in developing OO software in today's industry.
jto@litwin.com (John O'Beck) (06/06/91)
se90wak@cc.brunel.ac.uk (Wael A Khalil) writes: > - Adopting a software development method and making sure that the > documentation is up to date will insure that the software will > be highly modifiable. > - Software engineering method is not enough, there is more to it. Most maintenance issues go straight back to module coupling and cohesion. If you are designing you system using cohesive modules that are strictly data coupled; you tend to maximize the amount of reusable code and minimize module interactions. This makes for highly modifiable and maintainable code. Proper implementation of a reasonable software engineering methodology will help you do this. Of course no methodology can do much for you if it is not implemented properly. Nothing will ever substitute for good engineering. Any methodology is nothing but a miter box. It is up to you to learn how to cut the joints and build the cabinet.
ftower@ncar.ucar.EDU (Francis Tower) (06/07/91)
In general, the traditional waterfall life-cycle fails when maintenance is concerned because those fine, fat documents which tell managers that a phase of the development is finished are left to gather dust. In particular the software specification is often never revised and the product begins to diverge from the specification. The result is that the source itself is maintained and both old and new optimization knowledge is spread into the source with details lost. Balzer, Cheatham and Green in their classic paper 'Software Technology in the 1990's: Using a New Paradigm' (IEEE Comp. Nov 1983) proposed that a program's specification be formalized and that the implementation be mostly automated. The problem then of maintainability would be pushed into the specification phase. With greater acceptence (more in Europe and Canada) specification languages are being used on software products (Specifying a Real-Time Kernal, IEEE Software Sept 1990; 'A Formal Specification of an Oscilloscope' IEEE Software, Sept 1990) and they are not only making the maintenance function more tractable, they are also detecting flaws in the specification as well as providing a tool for exploring the effects of changes. If you are not using some form of formal specification then the longer and more frequently a program is modified, the more calcified it becomes. Decisions made long ago on data structures and optimizations act as ruts to force maintanance into a narrow track. My suggestions in this case are: 1. A concise guide to programming style and practices, 2. Choice of a minimal set of allowable structures 3. Elimination of program optimization, 4. High degree of modularity with as much generic code as possible, 5. Effictive QA and CM functions with management involvement on projects.
jls@netcom.COM (Jim Showalter) (06/07/91)
>I would like to learn more about such methodology, and if you (or any one else >can point out those methodologies, are they used in industry, what kind of >application? The neture of the development infra-structure? Are there >none-Object Oriented methods. What is the minimum support needed form the >development environment/programming language. I have described this method elsewhere. It is not all that remarkable (people seem to expect ACA [Another Clever Acronym] or ASB [Another Sexy Buzzword], when all this is is the codification of common sense). Prototype. Iterate. Embrace feedback. Focus on architecture and design--coding is trivial in comparison. Emphasize reusability, maintainability, and line-of-business concerns (e.g. if you build air defense systems for a living, why not acknowledge that fact up front and build an architecture that is broadly applicable to air defense systems?). Implement in a software-engineering- oriented language (may I suggest Ada?). Use industrial-strength tools. Make documentation subservient to design, not the other way around. Look for objects and classes in the design--but don't get so carried away you wind up torturing the language to make verbs into nouns. Tune for performance, don't let a focus on performance distort your entire design. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
iverson@xstor.com (Tim Iverson) (06/07/91)
In article <2192@Terra.cc.brunel.ac.uk> se90wak@cc.brunel.ac.uk (Wael A Khalil) writes: >I would like to initiate a discussion on maintainability! >there are two main positions that people (and literature) take on how to >produce miantainable (and modifiable) software: > - Adopting a software development method and making sure that the > documentation is up to date will insure that the software will > be highly modifiable. If the method is up to snuff, rabid application of it should produce results that are easy to modify and maintain. It helps if those criteria (maintainable and modifiable) are held to be more important than than other, perhaps contradictory, criteria (such as short term results). > - Software engineering method is not enough, there is more to it. My opinion is that the ability to produce lucid and concise expressions in the written tongue used in the project (btw, this *must* be english - even the danes don't know what P() and V() stand for :-) can add a great deal to the effort. The main use of a design document is to communicate your design to others. If you are hard to understand, your design will be hard to understand and it will be hard for others to modify. After all, the first step in any attempt at modification is to answer the question, "Where are we now?". If the answer is less than clear, it will be harder to answer the subsequent questions of "Where do we want to be?" and "How do we get there?". Worse, you may end up saying, "How did I get here?", "This is not my house!", "This is not my beautiful wife!", ... - Tim Iverson iverson@xstor.com -/- uunet!xstor!iverson
jls@netcom.COM (Jim Showalter) (06/07/91)
>The main use of a design document is to communicate your design to others. >If you are hard to understand, your design will be hard to understand and it >will be hard for others to modify. Einstein was fond of saying that if you can't explain to an 8 year old what you are doing, you obviously don't know. Using this metric, I've seen precious few design documents written by people who know what they're building. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
kers@hplb.hpl.hp.com (Chris Dollin) (06/07/91)
Jim Showalter says (including lots of Good Things): Implement in a software-engineering-oriented language (may I suggest Ada?). Program design is language design. Since you'd probably like to write in a language suitable for the domain, why not face the fact, invest in language processing techniques, write the system in a ``suitable'' language, and compile (not necessarily into machine code) the result? It doesn't much matter then what language you had around to begin with, although it's nice if you can coerce it into being a suitable compilation target. -- Regards, Kers. "If anything anyone licks, they'll find it all ready in sticks."
kers@hplb.hpl.hp.com (Chris Dollin) (06/07/91)
Jim Showalter says (in response to a posting):
Einstein was fond of saying that if you can't explain to an 8 year
old what you are doing, you obviously don't know. Using this metric,
I've seen precious few design documents written by people who know
what they're building.
Casting aside the appeal to authority, how reasonable is this test (``metric''
seems a little to overstate the case, since the only number involved is the age
``8''. Hm, another software metric - an average of the developers ages?)?
Could you explain to an 8-year-old:
* that you're computing a transitive closure
* that you're generating code to parse tokens froma context-free grammar
* that you're proving that launching requires authorisation
* that you drink beer because you *like* the taste
* that sex is nicer than chocolate [points for identifying source]
* that people have to lose their jobs to support the economy
``explain'', ``what you're doing'', and how you measure the success of the
explanation are all left loose here. I'd give the criterion a polite ``no'',
but admit that there's something to be learned from it.
--
Regards, Kers.
"If anything anyone licks, they'll find it all ready in sticks."jcardow@afit.af.mil (James E. Cardow) (06/07/91)
jls@netcom.COM (Jim Showalter) writes: >>I would like to initiate a discussion on maintainability! >>there are two main positions that people (and literature) take on how to >>produce miantainable (and modifiable) software: >> - Adopting a software development method and making sure that the >> documentation is up to date will insure that the software will >> be highly modifiable. >If one adopts a software development method that is worth anything, then >one should wind up, as a consequence, with software that is maintainable >and modifiable. Another way to put this is that one of the criteria for >selecting a software development method is that the method, properly >applied, should result in software that is maintainable and modifiable. >The question then becomes: are there software development methods that >result in maintainable and modifiable software and, if so, what are >they? This question, I answer with a resounding yes: a method that stresses >architecture and design, rapid prototyping, iterative development, incremental >delivery of functionality and documentation, abstraction, and all the other >stuff that has been discussed in this group is such a method. I've seen >such a method followed in real life on real projects of significant scope >and complexity, and I've seen highly maintainable and modifiable software >result from it. >-- First off, I'm not willing to accept that this is not maintenance, I believe this is properly preparing for maintenance (corrective and enhancement). Second, part of the problem is "all the other stuff." There are many things out there that will result in *some aspect* of a more maintainable system, but what does the compination or net effect cause. Can I make a selection of these methods and still keep the quality? I have heard about the software process and process modeling for several years. And, to be honest, considered it to be one more be-all solution to the software problem. At first, I thought it was hype. Then I saw some benefit in that it provided a way to improve business by structure. Then I saw it as a way to smartly include some things that made sense (SQA, CM, etc). Now I realize that it isn't a solution at all, but a good way to address that problem. A good way to address that problem in that I am faced with a score of solutions to each day-to-day occurance. Many of the solutions solving their own intended problem, but at the expense of many new problems. What a process does is generate a framework to explore solutions in, that keeps all the pieces in a bundle. So, when I look at issues like maintainability (primarily, understand- abilit) I can look at all aspects of the process and what effect new technologies will have. I think a more beneficial approach to the discussion might be WHAT is Understand-ability Or how do I guage Maintainability? Looking forward to the discussion. Jim Cardow, Capt, USAF Air Force Institute of Technology Instructor in Software Engineering Professional Continuing Education Program E-mail: jcardow@blackbird.afit.af.mil
orville@weyrich.UUCP (Orville R. Weyrich) (06/07/91)
In article <11714@ncar.ucar.edu> ftower@ncar.ucar.EDU (Francis Tower) writes: >In general, the traditional waterfall life-cycle fails when maintenance is >concerned because those fine, fat documents which tell managers that a phase of >the development is finished are left to gather dust. In particular the >software specification is often never revised and the product begins to >diverge from the specification. The result is that the source itself is >maintained and both old and new optimization knowledge is spread into the >source with details lost. I agree. >Balzer, Cheatham and Green in their classic paper 'Software Technology in the >1990's: Using a New Paradigm' (IEEE Comp. Nov 1983) proposed that a program's >specification be formalized and that the implementation be mostly automated. >The problem then of maintainability would be pushed into the specification >phase. The problem with this is that the specification becomes to all intents and purposes the programming language, and if Ada or C (or something else) is later generated automatically from this specification, its just an intermediate pass of a huge compiler. In effect, the specification language becomes the language in which the source code is written. What are the implications then of Balzer et al's paper? 1) Source languages should be more formal so that more consistency checking can be done. [There has been some movement in this direction. Eiffel for example allows assertions as part of the language. SETL provides a formal framework. IMHO there is progress, but a long way to go. It is not clear to me that many of today's programmers are willing or able to go the distance here.] 2) The amount of work done prior to beginning coding should be minimized. [At first blush, this is contrary to conventional wisdom. But it is not really, if the coding environment supports stepwise refinement and consistency checks along the way. Consider the use of Ada as a PDL as movement in this direction.] -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
johnson@cs.uiuc.EDU (Ralph Johnson) (06/08/91)
In article <1991Jun6.230049.19029@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: |> |> ... Prototype. Iterate. |> Embrace feedback. Focus on architecture and design--coding is trivial in |> comparison. Emphasize reusability, maintainability, and line-of-business |> concerns (e.g. if you build air defense systems for a living, why not |> acknowledge that fact up front and build an architecture that is broadly |> applicable to air defense systems?). This point of view is at the heart of the Smalltalk culture. I think that the reason why Jim (Objects with Ada) Showalter and Kent Beck (to pick one example) have similar world-views has little to do with the fact that they both call what they do "object-oriented programming". Instead, this is the point of view of someone who has really tried to develop reusable software. In fact, the way I tell whether someone has had any practical experience developing reusable software or not is whether they believe what Jim said. Thanks for a good summary, Jim. One of the things that I tend to emphasize is that it is impossible to invent a general-purpose widget unless you know how to build special-purpose ones. Humans develop abstractions by generalizing from concrete examples. Applied to software, this means that unless you have build some nonreusable software in a particular application domain, you don't stand much chance of building reusable software. That is why iteration is so important. People tend to build something concrete that works, and then gradually generalize it as it becomes obvious that it is a special case of a more general idea. Ralph Johnson -- University of Illinois at Urbana-Champaign
jls@netcom.COM (Jim Showalter) (06/08/91)
>Could you explain to an 8-year-old: > * that you're computing a transitive closure Yes. > * that you're generating code to parse tokens froma context-free grammar Yes. > * that you're proving that launching requires authorisation Yes. > * that you drink beer because you *like* the taste No. Particularly since I'm sure I drink beer both because I like the taste and because I like the buzz. > * that sex is nicer than chocolate [points for identifying source] No. At least not legally... > * that people have to lose their jobs to support the economy No. Even an 8 year old is smart enough to detect bovine scatology. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jls@netcom.COM (Jim Showalter) (06/08/91)
>One of the things that I tend to emphasize is that it is impossible to >invent a general-purpose widget unless you know how to build special-purpose >ones. Humans develop abstractions by generalizing from concrete examples. >Applied to software, this means that unless you have build some nonreusable >software in a particular application domain, you don't stand much chance of >building reusable software. That is why iteration is so important. People >tend to build something concrete that works, and then gradually generalize >it as it becomes obvious that it is a special case of a more general idea. Yes, you have to build one to throw away before you can figure out how to achieve reuse. Reuse is acquired through experience and trial-and-error. People don't like this idea, because it means they have to PLAN to fail for a while, but the upside is that most companies already have sufficient domain expertise (they've been doing the same kind of thing for years) that the number of iterations necessary is fairly small. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
anthony@cs.uq.oz.au (Anthony Lee) (06/09/91)
In <1991Jun7.165928.1903@weyrich.UUCP> orville@weyrich.UUCP (Orville R. Weyrich) writes: >>Balzer, Cheatham and Green in their classic paper 'Software Technology in the >>1990's: Using a New Paradigm' (IEEE Comp. Nov 1983) proposed that a program's >>specification be formalized and that the implementation be mostly automated. >>The problem then of maintainability would be pushed into the specification >>phase. >The problem with this is that the specification becomes to all intents and >purposes the programming language, and if Ada or C (or something else) is >later generated automatically from this specification, its just an intermediate >pass of a huge compiler. >In effect, the specification language becomes the language in which the >source code is written. I disagree, there are two problems with trying modify a software from a natural language specification. 1. The specification is most likely to be ambigious and the designer of the modification has to make the best **guess**. 2. It is very difficult for the designer of the modification to figure out the effect of his modification on the existing software. Formal specification is more than just a higher level programming language. It allows the designer of the modification to reason about the effects of his modification on the rest of the system. Furthermore you have to consider that the modification could have taken place several months after the delivery of the original product (or even years). How can you guarantee that the source code of the original product would be available. Even if the source code was availabe it far more difficult to analysis for conflicting properties between existing software and new software at the source level. -- Anthony Lee (Michaelangelo teenage mutant ninja turtle) (Time Lord Doctor) email: anthony@cs.uq.oz.au TEL:+(61)-7-365-2697 (w) SNAIL: Dept Comp. Science, University of Qld, St Lucia, Qld 4072, Australia
matt@bacchus.esa.oz (Matt Atterbury) (06/10/91)
In article <11714@ncar.ucar.edu> ftower@ncar.ucar.EDU (Francis Tower) writes:
In general, the traditional waterfall life-cycle fails when maintenance is
concerned because those fine, fat documents which tell managers that a`
phase of the development is finished are left to gather dust. ...
This classic cycle is discussed by Jonathan Grudin in April '91's
'Computer' [published by the IEEE computer society]. He puts some of
the blame for the failure of the waterfall life-cycle on the fact that
systems are now highly interactive so cannot be formally specified
properly _up-front_ [i.e. there has to be interaction between
developer and user to determine the UI, although the functionality can
be specified as long as it is not too affected by the UI].
Balzer, Cheatham and Green in their classic paper 'Software Technology in
the 1990's: Using a New Paradigm' (IEEE Comp. Nov 1983) proposed that a
program's specification be formalized and that the implementation be mostly
automated.
Jackson [JSP/JSD] also argues for "compilable designs", basically
saying that assuming one can come up with an implementation
_independent_ design, it would be logical to assume that this can then
be compiled into whatever language you like. I don't know his opinions
on compilable specifications, but IMHO, a specification cannot be
compiled precisely because it is that: a definition of what is to be
done, NOT how to do it. Can you see how to compile a VDM spec into C ?
(BTW, I cannot believe the D in VDM stands for Design! never in a
million years can a VDM spec be called a _design_ IMHO!!!!).
The problem then of maintainability would be pushed into the specification
phase.
Where it belongs, since assuming correctness of the implementation,
subsequent changes must be due to changes in the desired specification.
...
If you are not using some form of formal specification then the longer and
more frequently a program is modified, the more calcified it becomes.
Unless you have a _compilable_ formal specification, you still have
these problems, since otherwise you haven't taken anything out of the
loop - you still have to design, code, test, debug you implementation.
--
-------------------------------------------------------------------------------
Matt Atterbury [matt@bacchus.esa.oz.au] Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari!matt@bacchus.esa.oz.au "klaatu barada nikto"
or: ...!uunet!murtoa!bacchus.esa.oz.au!matt "consider this a divorce"
ARPA: matt%bacchus.esa.oz.AU@uunet.UU.NET "life? don't talk to me about life!"warack@dip.eecs.umich.edu (Christopher Warack) (06/10/91)
In article <1849@uqcspe.cs.uq.oz.au> anthony@cs.uq.oz.au writes: >In <1991Jun7.165928.1903@weyrich.UUCP> orville@weyrich.UUCP (Orville R. Weyrich) writes: >>The problem with this is that the specification becomes to all intents and >>purposes the programming language, and if Ada or C (or something else) is ************************ >>later generated automatically from this specification, its just an intermediate >>pass of a huge compiler. > >>In effect, the specification language becomes the language in which the >>source code is written. > >I disagree, there are two problems with trying modify a software from a >natural language specification. > >1. The specification is most likely to be ambigious and the >designer of the modification has to make the best **guess**. I think we're seeing two ways of looking at this problem. Yes, the spec could be ambiguous. I don't believe Balzer "required" full automation; programmer interaction during the code generation phase, guided by automation, was the plan. But, if you take the other position that the spec is not ambiguous, then you need something as rich as the program written in a HOL to describe it. If the code is not necessary, why was it in the program to begin with. There is some amount of code "infrastructure" such as setting up the execution environment or manually implementing high-level structures such as exceptions that could probably be ignored in a specification. I'd assert, however, that more than 95% of a reasonably sized program's code is an attempt at writing a non-ambiguous specification. 1/2 :-) >2. It is very difficult for the designer of the modification >to figure out the effect of his modification on the existing >software. Formal specification is more than just a higher level >programming language. It allows the designer of the modification >to reason about the effects of his modification on the rest of >the system. I believe that designers of programming languages also desire this ability...??? While simplification of a problem may make it easier to reason about, it may also tend to hide the characteristics/ behavior that cause the problem. >Furthermore you have to consider that the modification could have >taken place several months after the delivery of the original >product (or even years). How can you guarantee that the source >code of the original product would be available. As easily as guaranteeing that the formal specification is available. >Even if the source code was availabe it far more difficult to analysis >for conflicting properties between existing software and new software >at the source level. than what? at the object level? Formal specification techniques of the kind that Balzer proposed don't exist yet, so you can't mean those, can you? -- Chris >-- >Anthony Lee (Michaelangelo teenage mutant ninja turtle) (Time Lord Doctor) >email: anthony@cs.uq.oz.au TEL:+(61)-7-365-2697 (w) >SNAIL: Dept Comp. Science, University of Qld, St Lucia, Qld 4072, Australia
jto@litwin.com (John O'Beck) (06/10/91)
orville@weyrich.UUCP (Orville R. Weyrich) writes: > ...>2) The amount of work done prior to beginning coding should be minimized. > [At first blush, this is contrary to conventional wisdom. But it is not > really, if the coding environment supports stepwise refinement and > consistency checks along the way. Consider the use of Ada as a PDL as > movement in this direction.] > How dows such a methodology allow communication between *many* programmers on a large project? How are changes to be communicated to and/or approved by management? Do all the bean counters need to learn Ada? Stepwise refinement of what? Consistency with what?
jto@litwin.com (John O'Beck) (06/10/91)
jls@netcom.COM (Jim Showalter) writes: >>One of the things that I tend to emphasize is that it is impossible to >>invent a general-purpose widget unless you know how to build >>special-purpose... >...Reuse is acquired through experience and trial-and-error. People don't >like this idea, because it means they have to PLAN to fail for a while, >but the upside is that most companies already have sufficient domain >expertise ... Any learning process is iterative. I think the real question is: How does an *organization* optimize the process of iteration? How are the lessons of trial and error communicated to newer members of the staff? All to often the same mistakes are repeated because junior staff members simply don't know any better. Formal peer review of deliverabales from each phase go along way toward addressing this. In most engineering disciplines reqirements, designs etc are reviewed to the hilt. Somehow, this seems to rarely happen with
ftower@ncar.ucar.EDU (Francis Tower) (06/10/91)
We are a long way from being able to generate code from specification languages but we have also come a long way from hand coding in machine language. It is possible to take a specification language and (with the help of a domain-specific automated assistant) produce a prototype program. This prototype can then be deconflicted with the user. Certainly, such a program wouldn't be able to meet performance requirements in time and space, but it would function. As I mentioned before, specification languages are being used to do just this and to gain insight into changes in the specification. The emphasis of Formal Methods has shifted to the area of specification because there demonstrable progress is being made which can be transitioned to the corporate & government world quickly (also there is more funding). Much remains to be done in terms of going from a formal spec to an executable program. But the worth of using formal spec languages is being demonstrated daily. However, there is always a natural resistance to change, not just in the fear of a new paradigm but also in finding/making the time to learn the language, techniques, implementation, training of programmers,.... The old ways work well enough and there is someone to ask questions. True. Software apprentices and prototypers in general do not yet exist. But! Specification Languages do and their use in maintanance/modification can prevent the premature aging of code.
mattel@auto-trol.com (Matt Telles) (06/10/91)
In article <KERS.91Jun7134939@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes: [ .. Some stuff deleted .. ] >Casting aside the appeal to authority, how reasonable is this test (``metric'' >seems a little to overstate the case, since the only number involved is the age >``8''. Hm, another software metric - an average of the developers ages?)? > >Could you explain to an 8-year-old: > > * that you're computing a transitive closure > * that you're generating code to parse tokens froma context-free grammar > * that you're proving that launching requires authorisation > * that you drink beer because you *like* the taste > * that sex is nicer than chocolate [points for identifying source] > * that people have to lose their jobs to support the economy > >``explain'', ``what you're doing'', and how you measure the success of the >explanation are all left loose here. I'd give the criterion a polite ``no'', >but admit that there's something to be learned from it. Chris, I don't usually post to this group, mostly because I have yet to understand how software can be engineering .. :). HOWEVER .. I agree with Jim and Einstein .. you CAN explain all of the above points to an 8 year old (Why 8? Because younger than that they do not have the concepts necessary to do proper comparisons). In the newspaper business, we were taught to write at an eight grade level. This works well in the news business because people do not have the time or desire to go to a dictionary for terms they do not understand in the morning daily. In the above points, with the exception of "sex being nicer than chocolate" (A Heinlein quote if I remember right..) I would be happy to explain any of the above to ANYONE over the age of 8. If you can't, as Jim pointed out, you do not understand the statement. Just my $.02. Matt -- ============================================================================== Matt Telles mattel@auto-trol.COM {...}ncar!ico!auto-trol!mattel Auto-trol Technology 12500 N Washington Denver, CO 80241-2404 (303)252-2874
jls@netcom.COM (Jim Showalter) (06/11/91)
>I'd assert, however, that >more than 95% of a reasonably sized program's code is an attempt at writing >a non-ambiguous specification. 1/2 :-) Excellent point, and a great way to succintly express my dissatisfaction with formal specification languages. I have seen such languages work well in a restricted domain (e.g. state transition tables), but in the larger scheme of things they either wind up too specific for the general case, or so general they are no longer concise. I am reminded of a time when a former employer was considering changing its method of implementing document generators from writing programs in Ada to using a textual grammar to write "meta-documents" that would then be compiled to Ada code via a translator. On the surface this new method had a lot of appeal--it would eliminate the need to write Ada code just to generate documents, it seemed like it would be an easier language to learn because it was specialized to document generation, it was closer to the end product (documentation) so it seemed like a more natural mapping between the problem space and the solution space, etc etc etc. On closer investigation, however, the scheme broke down: we kept finding places where we would need to add more complexity to the specification language in order to handle this or that case that had arisen in the course of generating documents, until the resulting grammar was nearly as complex as Ada itself but WITHOUT a base of commercially available parsers, formatters, editors, compilers, debuggers, etc. Yes, we considered the hybrid strategy of providing a general grammer for 80% of the cases with an escape-to-Ada mechanism for the trickier cases, but we realized that this made nobody particularly happy--now the implementor was faced with mastering TWO programming languages, plus which the onus of providing a means of communication among the various Ada-escapes was placed on the implementor (how, for example, do you hand global state back and forth between separated invocations of individual Ada programs?...). In the end, we concluded that the initial appeal of "simplicity" for the textual strategy didn't hold up under analysis, and that sticking with pure Ada implementation was the superior strategy. I think there is a lesson here for anyone who wants to specify systems in a formal language--it may well be the case that any time one wants to formally specify a system of suitable complexity to be interesting, the resulting specification language is itself so complex that it provides scant improvement over English or, alternatively, the language of implementation itself. (There are certainly development groups I'm aware of that use Ada as their specification and implementation language.) -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
sophatsa@enuxha.eas.asu.edu (Peraphon Sophatsathit) (06/11/91)
In article <MATT.91Jun10135455@henry.bacchus.esa.oz>, matt@bacchus.esa.oz (Matt Atterbury) writes: > (BTW, I cannot believe the D in VDM stands for Design! never in a > million years can a VDM spec be called a _design_ IMHO!!!!). VDM stands for Vienna Development Method. Regards, Peraphon
jls@netcom.COM (Jim Showalter) (06/11/91)
Earlier on this thread I posted a summary of a methodology that I have seen used on real projects and that results in modifiable and reusable code. In that posting, I said that one should tune for performance, but not let an obsession with performance pervert the architecture. In response, D.C.Sessions sent me some e-mail as follows (with permission to post and comment): > Something doesn't sound quite right here. While I agree that > microperformance is the bugaboo of small minds, I must take exception > with the notion that performance can IN ALL CASES be tuned in where > it wasn't designed in. > > Just as, in a hardware design, the basic architecture can make or break > a design (imagine using a Z80 for radar image analysis!), some software > architectural decisions can make acceptable performance impossible. By > the previous analogy, once you've designed in a Z80, all the clock > speedups and wait-state reductions in the world won't help. No argument. I was posting a summary, and as is the case with most summaries, some details were excluded that definitely need to be elaborated upon in a fuller discussion. I strongly agree that issues of macro-performance must be taken into account when designing the architecture--my remarks about performance tuning concern premature obsession with micro-efficiency issues when they can have no real impact on overall system performance. At every level of granularity of focus, from architecture down to coding individual lines, performance should be taken into account. The trick is to make sure that the proper KIND of performance issue is taken into account at the appropriate time. Worrying about register allocation peculiarities of this or that chip before you've settled on a networking scheme is silly. On the other hand, never worrying about such issues is sloppy, unless you have cycles to burn (and nobody ever does). One of the reasons I'm such a strong proponent of languages and tools that allow a rigorous specification of interfaces (at various levels of scale, including the subsystem level) is that such interfaces tend to focus one's attention on that which is essential at that particular level of detail. (This is nothing radical--it's the fundamental basis for abstraction...) -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
bowen@prg.ox.ac.uk (Jonathan Bowen) (06/11/91)
In article <1991Jun10.174641.8176@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >>I'd assert, however, that >>more than 95% of a reasonably sized program's code is an attempt at writing >>a non-ambiguous specification. 1/2 :-) > >Excellent point, and a great way to succintly express my dissatisfaction >with formal specification languages. I have seen such languages work well >in a restricted domain (e.g. state transition tables), but in the larger >scheme of things they either wind up too specific for the general case, >or so general they are no longer concise. > > ... > >I think there is a lesson here for anyone who wants to specify systems >in a formal language--it may well be the case that any time one wants >to formally specify a system of suitable complexity to be interesting, >the resulting specification language is itself so complex that it provides >scant improvement over English or, alternatively, the language of >implementation itself. You might be interested in the work at IBM, Hursley Park, in the UK. They have specified part of CICS (a commercial transaction processing system) in the formal specification notation Z and have coded (or recoded) 100,000+ lines of program from these specifications. The overall development cost and number of errors detected have been reduced, although there are significant (one-off) educational costs to retrain employees. See the following reference for further details: @article{Z:Nix88, author = {C.J. Nix and B.P. Collins}, title = {The use of Software Engineering, including the {Z} Notation, in the Development of {CICS}}, journal = {Quality Assurance}, volume = {14}, number = {3}, pages = {103-110}, month = {September}, year = {1988} } You should also look at the September 1990 special issue of IEEE Software on formal methods; in particular: @article{Z:Hall90b, author = {Anthony Hall}, title = {Seven Myths of Formal methods}, journal = {IEEE Software}, pages = {11-19}, month = {September}, year = {1990}, annote = { Formal methods are difficult, expensive, and not widely useful, detractors say. Using a case study and other real-world examples, this article challenges such common myths.} } The following myths are systematically covered: * Formal methods can guarantee that software is perfect. * They work by proving that programs are correct. * Only highly critical systems benefit from their use. * They involve complex mathematics. * They increase the cost of development. * They are incomprehensible to clients. * Nobody uses them for real projects. -- Jonathan Bowen, <Jonathan.Bowen@prg.oxford.ac.uk> Oxford University Computing Laboratory.
straub@jogger.cs.umd.edu (Pablo A. Straub) (06/11/91)
In article <1991Jun11.004620.3157@netcom.COM> Jim Showalter writes: > [... on the problem of designing performance vs. tuning performace] > >One of the reasons I'm such a strong proponent of languages and tools that >allow a rigorous specification of interfaces (at various levels of scale, >including the subsystem level) is that such interfaces tend to focus one's >attention on that which is essential at that particular level of detail. >(This is nothing radical--it's the fundamental basis for abstraction...) I agree. Of course, the only way to specify rigorously an interface is using a language in which both syntax and semantics are unambiguosly specified. That is, formal specifications are a must. >**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 *************** Pablo Straub, straub@cs.umd.edu
anthony@cs.uq.oz.au (Anthony Lee) (06/12/91)
In <1991Jun10.122656.18795@zip.eecs.umich.edu> warack@dip.eecs.umich.edu (Christopher Warack) writes: >There is some amount of code "infrastructure" such as setting up the execution >environment or manually implementing high-level structures such as exceptions >that could probably be ignored in a specification. I'd assert, however, that >more than 95% of a reasonably sized program's code is an attempt at writing >a non-ambiguous specification. 1/2 :-) That is true the program's code is itself a specification. The problem of modifiability depends on the level that we are working on. However if we don't deal with problem of modifiability at the specification level then they don't go away at the implementation level. This means that not only do you have deal with implementation issues that will affect modifiablity but you also have to deal with specification issues that is being carried forward because you didn't bother with them at the specification level. >I believe that designers of programming languages also desire this >ability...??? While simplification of a problem may make it easier >to reason about, it may also tend to hide the characteristics/ >behavior that cause the problem. Again, I point out that modifiability problem at the high level don't just go away at the implementation level. If you can knock those problems over the head at the specification level then the problem at the implementation level would be easilier to deal with. >>Furthermore you have to consider that the modification could have >>taken place several months after the delivery of the original >>product (or even years). How can you guarantee that the source >>code of the original product would be available. >As easily as guaranteeing that the formal specification is available. Most companies are very reluctant to hand over code but the specification is alway part of the contract. In fact it is the contract. If we insist that the contract be written formally then we will always have it with us. >>Even if the source code was availabe it far more difficult to analysis >>for conflicting properties between existing software and new software :>at the source level. >than what? at the object level? Formal specification techniques of the >kind that Balzer proposed don't exist yet, so you can't mean those, can you? >-- Chris >>-- >>Anthony Lee (Michaelangelo teenage mutant ninja turtle) (Time Lord Doctor) >>email: anthony@cs.uq.oz.au TEL:+(61)-7-365-2697 (w) >>SNAIL: Dept Comp. Science, University of Qld, St Lucia, Qld 4072, Australia -- Anthony Lee (Michaelangelo teenage mutant ninja turtle) (Time Lord Doctor) email: anthony@cs.uq.oz.au TEL:+(61)-7-365-2697 (w) SNAIL: Dept Comp. Science, University of Qld, St Lucia, Qld 4072, Australia
warack@dip.eecs.umich.edu (Christopher Warack) (06/12/91)
I don't know what exactly happened here; but it's some kind of context switch. I thought this piece of thread had headed off into the topic of automatic programming where the program is generated "mechanically" from the specification. I argued that this requires a spec to be nearly as complex as the implementation. Thus, eliminating real improvement over traditional HOL implementation (except in certain well-understood application areas). This is NOT the spec that comes with a contract. If it is, why is the customer letting a contract, they've already done the work. I agree completely that specs should address maintainability concerns. This issue is independent of formal/non-formal and automatic programming arguments except to the extent that they may make it easier to specify maintainability concerns. I haven't seen any clear advantage in any of them. Furthermore, I have absolutely no qualms about the "traditional" approach which states you should maintain your spec and design as well as your code. Abstraction is good and should be maintained. I also understand why this doesn't happen all that often. In fact, it's quite possible that formal specs may make this easier, since one of the big problems with abstraction maintenance is "traceability." A good formal method should relate better to the implementation and be more traceable. Just trying to keep the swap space clean :-) -- Chris In article <1893@uqcspe.cs.uq.oz.au> anthony@cs.uq.oz.au writes: >In <1991Jun10.122656.18795@zip.eecs.umich.edu> warack@dip.eecs.umich.edu (Christopher Warack) writes: > >>There is some amount of code "infrastructure" such as setting up the execution >>environment or manually implementing high-level structures such as exceptions >>that could probably be ignored in a specification. I'd assert, however, that >>more than 95% of a reasonably sized program's code is an attempt at writing >>a non-ambiguous specification. 1/2 :-) > >That is true the program's code is itself a specification. The problem >of modifiability depends on the level that we are working on. >However if we don't deal with problem of modifiability at the specification >level then they don't go away at the implementation level. This means >that not only do you have deal with implementation issues that will >affect modifiablity but you also have to deal with specification issues >that is being carried forward because you didn't bother with them >at the specification level. > >>I believe that designers of programming languages also desire this >>ability...??? While simplification of a problem may make it easier >>to reason about, it may also tend to hide the characteristics/ >>behavior that cause the problem. > >Again, I point out that modifiability problem at the high level >don't just go away at the implementation level. If you can knock >those problems over the head at the specification level then the >problem at the implementation level would be easilier to deal with. > >>>Furthermore you have to consider that the modification could have >>>taken place several months after the delivery of the original >>>product (or even years). How can you guarantee that the source >>>code of the original product would be available. > >>As easily as guaranteeing that the formal specification is available. > >Most companies are very reluctant to hand over code but the specification >is alway part of the contract. In fact it is the contract. >If we insist that the contract be written formally then we will always >have it with us. > > >>>Even if the source code was availabe it far more difficult to analysis >>>for conflicting properties between existing software and new software >:>at the source level. > >>than what? at the object level? Formal specification techniques of the >>kind that Balzer proposed don't exist yet, so you can't mean those, can you? > >>-- Chris > >>>-- >>>Anthony Lee (Michaelangelo teenage mutant ninja turtle) (Time Lord Doctor) >>>email: anthony@cs.uq.oz.au TEL:+(61)-7-365-2697 (w) >>>SNAIL: Dept Comp. Science, University of Qld, St Lucia, Qld 4072, Australia >-- >Anthony Lee (Michaelangelo teenage mutant ninja turtle) (Time Lord Doctor) >email: anthony@cs.uq.oz.au TEL:+(61)-7-365-2697 (w) >SNAIL: Dept Comp. Science, University of Qld, St Lucia, Qld 4072, Australia
mcgregor@hemlock.Atherton.COM (Scott McGregor) (06/13/91)
In article <1991Jun10.174641.8176@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: >I'd assert, however, that >more than 95% of a reasonably sized program's code is an attempt at writing >a non-ambiguous specification. 1/2 :-) > Excellent point, and a great way to succintly express my dissatisfaction > with formal specification languages. I have seen such languages work well > in a restricted domain (e.g. state transition tables), but in the larger > scheme of things they either wind up too specific for the general case, > or so general they are no longer concise... > I think there is a lesson here for anyone who wants to specify systems > in a formal language--it may well be the case that any time one wants > to formally specify a system of suitable complexity to be interesting, > the resulting specification language is itself so complex that it provides > scant improvement over English or, alternatively, the language of > implementation itself. The flip way to look at what this might mean to formal language designers is what Jim pointed out in the first paragraph. Conciseness and clarity can be critical to a new language being a significant improvement over another language. Scale matters: you can only see so much at a glance, on a page, or on a monitor. As you exceed those levels you quickly overwhelm the user with complexity. It takes a very clever designer to create a new representation that is significantly more compact in physical representation and things needing to be learned, and yet at the same time which has enough clarity that the symbols are easily learned, recognized, and understood in context. There are only a very few basic prototypical language forms in common use today: lisp-style derivatives, algol-style derivatives, unix-command line style derivatives, troff style markup derivatives, spreadsheet derivatives, 4GLstyle descriptive languages, and a few iconic languages. Far and away the most common base for new languages is the algol style. It is not clear that this is as wise a choice as the overwhelming preference seems to indicate--some of the other forms, or forms not yet invented or in common use might be much better. Rather selection of the algol style language form may be driven by other factors such as the availability of parsers and compiler-compiler technology for this form (e.g. lex and yacc) and the high level of familiarity of programmers with this style (both in day to day use, and in classes on building compilers from school days). Familiarity with this form and tools might argue for its use in terms of quickest implementation, but overlooks whether this form will be best for the task at hand. I think this is especially important to consider this because technology has provided reduced cost display technology with many more "degrees of freedom" for designers than the old monochrome 80 char wide Ascii only teletypes for which most of the above forms such as the algol style were developed. The use of color, alternate fonts, non-character symbols, 2D and 3D spatial locations, varying line widths, animation, etc. available on todays monitors offers the potential for design of new languages (both schematic and textual) which use more of these degrees of freedom to achieve greater compactness. By and large today's designers have ineffectually taken advantage of these new degrees of freedom, but they do offer hope for improvements over past results. Scott McGregor Atherton Technology mcgregor@atherton.com
orville@weyrich.UUCP (Orville R. Weyrich) (06/13/91)
In article <1991Jun10.130548.13815@litwin.com> jto@litwin.com (John O'Beck) writes: >orville@weyrich.UUCP (Orville R. Weyrich) writes: > >> ...>2) The amount of work done prior to beginning coding should be minimized. >> [At first blush, this is contrary to conventional wisdom. But it is not >> really, if the coding environment supports stepwise refinement and >> consistency checks along the way. Consider the use of Ada as a PDL as >> movement in this direction.] >> > > How dows such a methodology allow communication between *many* programmers > on a large project? How are changes to be communicated to and/or > approved by management? Do all the bean counters need to learn Ada? > Stepwise refinement of what? Consistency with what? > I was commenting on Balzer et al.'s proposed paradigm for the 90's. It does not yet exist. Yes, communication and CM are problems. See comp.groupware and alt.hypertexxt for discussions of this topic. Stepwise refinement of the specification, of course. A useful formal specification language must have some construct of the form STUB(informal stuff). INTERNAL consistency; no loose ends. -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
tsarver@andersen.uucp (Tom Sarver) (06/19/91)
In article <1991Jun12.115602.4153@zip.eecs.umich.edu> warack@dip.eecs.umich.edu (Christopher Warack) writes: >I don't know what exactly happened here; but it's some kind of context >switch. I thought this piece of thread had headed off into the topic of >automatic programming where the program is generated "mechanically" from >the specification. I argued that this requires a spec to be nearly as >complex as the implementation. Thus, eliminating real improvement over >traditional HOL implementation (except in certain well-understood >application areas). This is NOT the spec that comes with a contract. If >it is, why is the customer letting a contract, they've already done the >work. > I believe that maintenance, modifiability, and re-use are all becoming very important to Andersen Consulting because more and more often we can't simply install and leave. We are getting into the systems management area where WE are the ones left maintaining the code on behalf of the client. We have also been selling software products, even more heavily in the last few years, which forces us to consider maintenance. In the past we could simply ask, "Does the system work?" Now we must ask, "Yes, but can it be maintained?" >I agree completely that specs should address maintainability concerns. >This issue is independent of formal/non-formal and automatic programming >arguments except to the extent that they may make it easier to specify >maintainability concerns. I haven't seen any clear advantage in any >of them. > The issues facing you when you've decided to create modifiable code are very similar to the issues of re-use. (The use of "component" in the rest of this message refers to any item or set of items at any granularity. For example, it could be function, program, or sub-system.) The perspective for re-use is to take a component of an existing system (or re-use library) and incorporate it into a new system. When modifying a system every component in the system *except* the component being modified is the unit of re-use. To paraphrase, the component being modified has the potential to "re-use" every other component in the system. (In practice, it will be a subset.) The issues for re-use/modification are: 1) You must understand the {system(modify) | unit of re-use} 2) You level, or granularity, of {re-use | modification} should be pre-determined. Since any component can be re-used during the modification 1) must surely hold. It is not easily proven, but I maintain, that 2) is the key to coding (or specifying, designing, etc 8^) a modifiable system. One can build components to be re-used at a given level of granularity. For example, one can design certain sub-components of a component to be "public," or called by other components. The remaining sub-components may require a certain context, or special error checking, or prerequisite components. There are many ways of designing for this, but probably the most common relates to data encapsulation. That is, all functions act on a certain set of data. >Furthermore, I have absolutely no qualms about the "traditional" approach >which states you should maintain your spec and design as well as your code. >Abstraction is good and should be maintained. I also understand why this >doesn't happen all that often. In fact, it's quite possible that formal >specs may make this easier, since one of the big problems with abstraction >maintenance is "traceability." A good formal method should relate better >to the implementation and be more traceable. > I suggest that this is an issue of "Does the code meet the spec?" With formal methods the problem is reduced, but not eliminated. The traditional approach is expensive because developers are attempting to maintain consistency between informal (text) or semi-formal (diagrams) documents and a very formal document (code). >Just trying to keep the swap space clean :-) >-- Chris > -- --Tom Sarver tsarver@andersen.com Andersen Consulting "Think straight; talk straight." 100 S. Wacker, Ste. 900, Chicago, IL 60606 (312) 507-4912 "If the Firm ever discovered my opinions, IT would summarily forget them."
scairns@zamboni..citib (Scott Cairns) (06/20/91)
In article <1991Jun7.165928.1903@weyrich.UUCP> orville@weyrich.UUCP (Orville R. Weyrich) writes: >In article <11714@ncar.ucar.edu> ftower@ncar.ucar.EDU (Francis Tower) writes: >>In general, the traditional waterfall life-cycle fails when maintenance is... >>(etc.) > >I agree. > >(blah, blah, blah) > >-------------------------------------- ****************************** >Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional >Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting >Fax: (602) 391-0023 (Yes! I'm available) ^^^^^^^^^^^^^^^^^^ It seems to me that if this guy spent less time on the net and more on marketing his services, he might be able to change his sig to read (NO! I'm not available!). BTW, in New York City, a PhD and a token gets you on the #4 train.
jls@netcom.COM (Jim Showalter) (06/22/91)
scairns@zamboni..citib (Scott Cairns) writes: >In article <1991Jun7.165928.1903@weyrich.UUCP> orville@weyrich.UUCP (Orville R. Weyrich) writes: >>In article <11714@ncar.ucar.edu> ftower@ncar.ucar.EDU (Francis Tower) writes: >>>In general, the traditional waterfall life-cycle fails when maintenance is... >>>(etc.) >> >>I agree. >> >>(blah, blah, blah) >> >>-------------------------------------- ****************************** >>Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional >>Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting >>Fax: (602) 391-0023 (Yes! I'm available) > ^^^^^^^^^^^^^^^^^^ >It seems to me that if this guy spent less time on the net and more on marketing >his services, he might be able to change his sig to read (NO! I'm not available!). >BTW, in New York City, a PhD and a token gets you on the #4 train. First of all, the simple fact is that consultants are ALWAYS available (a little "feature" of the job I'm finding increasingly less charming the longer I do this for a living)--even when working on a current contract they're eyeing the next one. It's basically part-time work for high pay. Secondly, I think this sort of flamage is totally uncalled for. As of late, the signal to noise ratio on all three of comp.object, comp.software-eng, and comp.lang.ada has been exceptionally good (particularly since I gave up trying to save C hackers from perdition), and I'd like to keep it that way. If I can learn to tone it down, ANYBODY can. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *