From brada@kiv.zcu.cz Fri Apr 24 08:54:46 1998 Date: Fri, 17 Oct 1997 10:18:27 +0200 From: Premek Brada To: brada@kiv.zcu.cz Subject: [Fwd: Re: Too many documents?] [ Part 1: "Included Message" ] Date: Tue, 14 Oct 1997 09:51:01 -0400 From: Ralph Cook Reply-To: rcook@pobox.com Newsgroups: comp.software-eng Subject: Re: Too many documents? Stuart Park wrote: > > I have recently been discussing the process of software changes with > another person at my workplace and came up with the following flow of > information: > > Customer Specification (documents exactly what the customer is > | asking for) > | > V > "Functional" Specification (written by senior analyst/programmer in > | consultation with project implementor, and > | describes what should be changed in the system > | to satisfy the customers requirement) > | > V > Technical Specification (written by the programmer doing the actual coding > | and describes the actual programs being changed, > | procedures being affected, etc) > | > V > > > Each of the specifications would be a separate document (possibly typed up > in Lotus or Word). This seems ok to me, but a comment was made that > management would see it as being too many documents and time-wasting. > My opinion is that with more information, you have a better chance of success. > > Opinions anyone? Yes, management may well perceive this as "too many documents and time-wasting", and that's a problem. Programmers/analysts/software engineers/whatever-we're-calling-ourselves- this-week may also see it as a waste of time. In general, people who write code do not enjoy writing documentation and don't see much value in it. I opine that all of that information must be understood clearly in order to have a reasonable chance at a good (satisfactory, well-engineered) system. The customer and technical people need to have the *same* understanding of that information. The chances of getting that understanding without the documents is very slim. You may have left out some other documentation that I consider imperative, and that is design documentation. The designers and coders, even if they are the same group of people, need to have a thorough understanding of how the system is (to be) implemented. Again, it is the written word that clarifies. Another benefit of good design documentation is that it can lead to better estimating of the amount of remaining work; I don't see another way to tell how long the project has left to run. You've also left out testing plans, etc. The industry produces lots of code which goes into production without that, but it is questionable whether doing without it is worth the risk of poor quality product. rc -- When I do speak for a company, I list my title and use "we". [ Part 2: "Included Message" ] Date: Wed, 15 Oct 1997 12:38:05 GMT From: Wayne Woodruff Newsgroups: comp.software-eng Subject: Re: Too many documents? I've used a similar model for many years. It forces you to think through the problem before implementation, thus saving you time and $$ later in the development cycle. You have already heard the most common criticism ... all of this takes too much time and it is too difficult to keep all of these up to date. The only practical way to manage this many documents is to use a Requirements Management tool. There are a few good ones on the market, I'm most familiar with RequisitePro (I use it, I do not work for them). You can develop your requirements specifications in Word and RequisitePro allows you to capture and link requirements from each of the specifications. Thus, when a customer changes a requirement, you know exactly the requirements in the lower level documents that need to be reviewed. Instead of reviewing the entire document, you can focus only on those areas impacted. This helps you estimate how much time will be actually be implementing the change. How many times has a hall-way conversation generated a "2 week" estimate to change the code, but does not consider how much time it will take to update the test plans and procedures, manuals, design specifications... you get my point. The 2 week estimate is more likely 2 months. These tools provide more capability than I can describe here, spend some time evaluating 1 or 2 of them and use one of them on a trial basis. It saves a bunch of time and improves quality. Info on RequisitePro can be found on the web at: http://www.rational.com/products/reqpro/index.html BTW, your model does not include User Manuals. If the manuals are based on the customer specification and it is not kept up to date, you will spend a lot of time correcting manuals. In article <61v3k5$4eb@psdcomms.psd.com.au>, Stuart Park (stuart@psd.com.au) writes: >I have recently been discussing the process of software changes with >another person at my workplace and came up with the following flow of >information: > >Customer Specification (documents exactly what the customer is > | asking for) > | > V >"Functional" Specification (written by senior analyst/programmer in > | consultation with project implementor, and > | describes what should be changed in the system > | to satisfy the customers requirement) > | > V >Technical Specification (written by the programmer doing the actual coding > | and describes the actual programs being changed, > | procedures being affected, etc) > | > V > > >Each of the specifications would be a separate document (possibly typed up >in Lotus or Word). This seems ok to me, but a comment was made that >management would see it as being too many documents and time-wasting. >My opinion is that with more information, you have a better chance of success. > >Opinions anyone? > > >-- >Stuart Park Melbourne, Australia >Senior Analyst/Programmer E-mail: stuart@psd.com.au >Prometheus Software > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Wayne Woodruff / / home page: http://www.jtan/~wayne \ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ -------------------------------------------------- Fri Apr 24 09:58:06 METDST 1998 From brada@kiv.zcu.cz Fri Apr 24 10:02:38 1998 Date: Fri, 17 Oct 1997 10:29:48 +0200 From: Premek Brada To: brada@kiv.zcu.cz Subject: [Fwd: Re: Advice? How can we get to an integrated tool set for a large, diverse team?] Steve Mellor wrote: > > For my money, the single biggest bang for the very smallest number > of bucks is to set up a _public document system_. > > That is, every pertitent 'document' (be it code, a description > of a problem, the project plan, whatever) has a identifier, and > it is stored in a known place (presumably soft, but hardcopy is fine) > Every document MUST have a date and/or version number, so you can > know which one you're talking about. And there needs to be a > document register (again, soft is good, hardcopy works too). > > There are add-ons to this: check in and out, published change list, > document standards etc etc, but you have to start somewhere. > > The biggest benefit of this approach is simple time-saving. Ever > spent several days trying to track down the latest version of > some document? Ever been told that Mary has a copy, but she's > on a trip? After all this, ever discover you got the wrong one? > This scheme reduces the communication paths, and the effort and > time involved. > > The second benefit is the notion that work is represented by > deliverables _and those deliverables are PUBLIC property_. > This is a first step toward taking an organization from > hackerland to even the simplest idea of process. > > And, of course, after that, I agree strongly with the following. > Note that the concept of inspection/review requires the idea > of public information. > > -- steve mellor > http://www.projtech.com > > L. Darrell Ray wrote: > > > > IMO you need to focus more on techniques and less on tools to start > > with. > > Try Inspections and\or reviews to and other techniques first and then > > after you have your Requirements\ High level Design. The industry avg. > > is that about 56% of defects injected here and most not found until > > coding or test. > > -------------------------------------------------- Fri Apr 24 10:00:59 METDST 1998 From brada@kiv.zcu.cz Fri Apr 24 10:04:37 1998 Date: Fri, 17 Oct 1997 10:39:29 +0200 From: Premek Brada To: brada@kiv.zcu.cz Subject: [Fwd: Re: documetation guides] scott.walsh@plantronics.com wrote: > > In article <01bcd97c$574764c0$0a000108@smirnoff.ideal.co.uk>, > "John Bell" wrote: > > > > Hi there, > > > > Can anyone recommend a good guide to writing solid software documentation, > > including req specs, func specs etc? I've found a few books on writing > > general technical documentation but nothing specifically geared towards > > software. > > > > Thanks, > > > > John Bell > > Try MIL-STD-498, all of the documentation is available from one of the > army.mil sites, sorry cant remember which. > > If you do read them, stick with it for a while, and make sure you read the > overview document first. > > The MIL-STD is not overkill, it has been sanitized over the past few > years. > > regards, > SW. > > -------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to Usenet -- Premek Brada "http://yoyo.zcu.cz/~brada/" Department of Computer Science, University of West Bohemia, Plzen, CZ -------------------------------------------------- Fri Apr 24 10:01:46 METDST 1998 From brada@kiv.zcu.cz Fri Apr 24 10:06:38 1998 Date: Fri, 17 Oct 1997 10:52:22 +0200 From: Premek Brada To: brada@kiv.zcu.cz Subject: [Fwd: So much crap in software] [ Part 1: "Included Message" ] [ Part 2: "Included Message" ] Date: Wed, 15 Oct 1997 12:52:57 -0600 From: ppgooding@hotmail.com Newsgroups: comp.software-eng Subject: So much crap in software This article is loosely centered around the following proposition: Begin: The reason why there is so much crap in software is that the buyers of software are willing to settle for crap, and pay top dollar for it. IN other words, there is a strong market for bad software. Software development will not mature until the market matures enough to make good software, and good software development, the clear choice over bad. End. Now, since this statement may be somewhat provocative and/or controversial, I would like to provide a little background: 1. The idea that there is a lot of crap in software development is not mine. The assertion was made in the midst of a thread whose origin had nothing to do with that subject, and in a newsgroup which is not directly aimed at the SE community (to wit, sci.physics). 2. The subject of good vs. bad software development is one which is dear to my heart. Vigilant devotees of comp.software-eng will know that I have engaged in some prolonged and heated _debates_ on this subject over the past year. Occasional thread storms on related subjects, such as process issues, break out in this newsgroup and have been observed to go on for weeks at a time. I have, myself, touched off a few of these storms with provocative postings or questions during the past year. At other times, I have simply watched from the sidelines and stayed out of the fray. 3. My own participation in these threads has been a personal experiment over the past year. I have found the experience to be at times fascinating, frustrating, uplifting, demoralizing, humbling, sickening, and exhausting. I have observed that those who post to these threads seem to mostly arrange themselves into _camps_ of thought, and that these camps wage war on each other with considerable vigor and relish, if not with much in the way of intellectual integrity or openmindedness. 4. I continue to believe that the general subject is the most important one in this venue. That is my personal opinion, and one which has been steadily reinforced since it first popped into my head about 9 years ago. I continue to seek opportunities for exploration of the general subject. Fresh from a long rest from posting into this newsgroup, I am once again (probably foolishly) optimistic that this venue can provide such opportunity. 5. Nine years of wrangling with these issues has led me to the proposition stated at the top of this article. Your thoughts? -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet [ Part 3: "Included Message" ] Date: Thu, 16 Oct 1997 10:18:37 -0400 From: "Scott P. Duncan" Newsgroups: comp.software-eng Subject: Re: So much crap in software > I believe that I heard on some news program that there > are actually exemptions for software companies from current product > liability laws. If anyone has more detailed or contrary info, please > speak!!! I have heard people speak over the past six months on the current pro- posed changes to the Universal Commercial Code which would affect the legal recourse a customer would have given software which does not per- form as advertised. Sectgion 2B of this code would, it appears, give producers of software virtul carte blanche to produce whatever they believe is good enough without fear of any customer ability to claim damages, refunds, etc. In effect, the shrink wrap licensing would be recognized as legitimate in that no warranties would apply to fitness for any use. The UCC is passed at the state legislature level and there is to be a meeting in Memphis next month to review the code as proposed. Such meetings, in the past, have been dominated by representatives of the software producers with almost no consumer representation whatsoever. >From the talks I have heard, one person named Cem Kaner has been the main voice opposing UCC 2B and has been successful in getting it delay- ed six months to this Memphis meeting. After that, it would likely go to state legislatures who have a reputation for passing such laws once they get out of the (industry) group that handles update proposals to UCC. For information as well as links to the actual text of the UCC, Kaner recently (at an ASQ Conference) offered the following: http://www.kaner.com and http://www.badsoftware.com The meeting will be at the Peabody Hotel in Memphis, Nov. 21-23 and ANYONE is permitted to attend and offer their opinions. Only members of the official body may vote on the actual proposal, however. I have no connection to anyone involved in this, but have found the discussions on what the changes would permit to be scary. Specifically, it would exempt software from any existing implied warranties under the UCC which other goods are expected to meet. And it sounds as though it would virtually eliminate any consumer recourse. The counter arguments offered seem to be that bug-free software is not possible and that laack of such protection for the U.S. software industry would ruin the US's position in the world economy for software. Kaner's position is that it would do just the opposite due to the lack of incen- tive to produce better software since the cost (and potential costs) of poor software would drop dramatically, encouraging foreign suppliers to challenge the U.S. with better quality products. Kaner uses the auto in- dustry as an example and sites various cases where the cost, figured in repair vs basic loss in lawsuits, was considered a risk worth taking until the rewards in the Pinto cases went well beyond the "average," ruining the insurance risk analysis expectations. If you are interested in legal implications regarding software liability, you should look over UCC 2B and perhaps consider contacting consumer and professional groups to urge them to participate. Indeed, the former have been unable to afford much participation and the latter, save some recent IEEE-CS attendance, have seemed unconcerned and/or unaware. [ Part 4: "Included Message" ] Date: Thu, 16 Oct 1997 07:44:01 -0500 From: Jeff Kotula Newsgroups: comp.software-eng Subject: Re: So much crap in software Panu Viljamaa wrote: > ppgooding@hotmail.com wrote: > > > The reason why there is so much crap in software is that the buyers > of > > software are willing to settle for crap, and pay top dollar for it. > IN > > other words, there is a strong market for bad software. Software > > development will not mature until the market matures enough to make > good > > software, and good software development, the clear choice over bad. > > Bad software is good - if it solves your problem. If the machine > crashes > occasionally, so what. Many other times it doesn't crash. It still > helps you. > The question is: "can we do even better ?" > > Brian Foote had a great paper in this year's PLoP where he argued that > > software is like cities. You have shanty-towns and Manhattans. > Eventually the > shanty-towns will develop into proper cities but never the less they > have an > important role right now, providing shelter from the storm. Sometimes > in > clever ways. > > - Panu Not a bad analogy. Unfortunately, we have too many people in the industrywho don't know how to build a Manhattan, are building shanty towns and asserting they are Manhattans, assert that Manhattans aren't desirable, or just can't tell the difference. I'd be happy if we could, on average, just build things that could stand up to a strong wind. I believe the hacker mentality that still pervades the industry (outside this newsgroup, of course :) is the cause of many of the problems. If you have to explain to someone who has been working in industry for years why checking pointer values *before* dereferencing them is essential to build good software, you're fighting a losing battle. The business side of the issue comes down to the short-term focus of virtually all businesses, executives, and managers. The true costs of poor quality products is never actually assessed because only initial development costs are tallied. If all maintenance, lost sales, and other related costs were added up on a regular basis, I think the short-term focus of business might change. (I know, I know, there are issues like time to market, market windows, blah blah blah. My point is that the business decisions are being made without complete and accurate information.) jeff [ Part 5: "Included Message" ] Date: 16 Oct 1997 17:31:00 GMT From: Justus Pendleton Newsgroups: comp.software-eng Subject: Re: So much crap in software In article <876937735.21267@dejanews.com>, ppgooding@hotmail.com wrote: [prologue cut] >1. The idea that there is a lot of crap in software development is not >mine. The assertion was made in the midst of a thread whose origin had >nothing to do with that subject, and in a newsgroup which is not directly >aimed at the SE community (to wit, sci.physics). More than once I've heard the explanation of why every electrical engineer or mathematician or (insert favorite non-SE career) thinks that programming is easy. In every field the majority of the critics have no direct experience in what they criticize. How many movie critics have written, directed, or starred in a motion picture? How many book critics have written a book? Software isn't really any different. I'm not saying that critics don't often have valid points---just that their criticisms are often based on a fairly simplistic world view. In a recent issue of IEEE Software (sorry I forget which one, I also forget who wrote it) there was a letter to the editor which talked about the differences between software development and other fields of engineering. The author argues that what is called engineering in other disciplines is more akin to software copying. He gives some examples of attempts at producing truly new products in other engineering disciplines (especially civil) -- and how miserably they have failed. He goes on to say that compared to other forms of engineering, software development is actual _admirable_ for the quality of new products produced (given the risks and innovation required of each and every product) -- and that other disciplines could perhaps learn something from it. [rest of article cut] -- Justus Pendleton justus.j.pendleton@lmco.com 5-7 percent of US businesses will go bankrupt as a reult of Y2K failures. -------------------------------------------------- Fri Apr 24 10:13:12 METDST 1998 From owner-otug-digest@Rational.Com Fri Apr 24 10:16:44 1998 Date: Thu, 23 Apr 1998 15:49:10 -0700 (PDT) From: otug-digest Reply-To: otug@Rational.Com To: otug-digest@Rational.Com Subject: otug-digest V1 #221 otug-digest Thursday, April 23 1998 Volume 01 : Number 221 ---------------------------------------------------------------------- Date: Thu, 23 Apr 1998 13:26:14 +1000 From: David Radnell Subject: Re: (OTUG) Adding robustness requirements to analysis A number of factors effect how robust (to changes) to build the software: 1. Will it ever be changed? 2. What changes are most likely? 2. The size and complexity of the infrastructure vs the size of the application (would it be simpler to re-write the application when changes arise) 3. Cost. 4. Murphys Law. Changes will occur that have not been predicted. Like any design decision sound engineering judgement must be used to determine how much infrastructre to build into a design. If certain changes are likely these can be specified in the requirements as design constraints. The design can then take them into account. Here is a lighthearted view: > Once upon a time, in a kingdom not far from here, a king summoned > two of his advisers for a test. He showed them both a shiny metal box > with > two slots on top, a control knob and a lever. "What do you think this > is?". > One adviser, an engineer, answered first. "It is a toaster." he said. The > king asked, "How would you design an embedded computer for it?". > The engineer replied, "Using a four-bit controller, I would write a > simple program that reads the darkness knob and quantifies its position to > > one of 16 shades of darkness, from snow white to coal black. The program > would use that darkness level as the index to a 16-element table of > initial > timer values. Then it would turn on the heating elements and start the > timer with the initial value selected from the table. At the end of the > time delay, > it would turn off the heat and pop up the toast. Come back next week, and > I'll show you a working prototype." > The second adviser, a computer scientist, immediately recognised the > danger of such short-sighted thinking. He said, "Toasters don't just turn > bread into toast, they are also used to warm frozen waffles. What you see > before you is really a breakfast food cooker. As the subjects of your > kingdom become more sophisticated, they will demand more capabilities. > They > will need a breakfast cooker that can also cook sausage, fry bacon and > make scrambled eggs. A toaster that only makes toast will soon be > obsolete. If we don't look to the future, we will have to completely > redesign > the toaster in just a few years". > "With this in mind, we can formulate a more intelligent solution to > the problem. First, create a class of breakfast foods. Specialise this > class into subclasses: grains, pork and poultry. The specialisation > process should be related, with grains divided into toast, muffins, > pancakes and waffles; pork divided into sausage, links and bacon; and > poultry > divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, > and various omelette classes." > "The ham and cheese omelette class is worth special attention > because it must inherit characteristics from the pork, dairy and poultry > classes. > Thus we see that the problem cannot be properly solved without multiple > inheritance. At run time, the program must create the proper object > and send a message to the object that say, "Cook yourself". The > semantics of this message depends, of course, on the kind of object, so > they > have a different meaning to a piece of toast than to scrambled eggs." > "Reviewing the process so far, we see that the analysis phase has > revealed that the primary requirement is to cook any kind of breakfast > food. > In the design phase, we have discovered some derived requirements. > Specifically, we need an object-oriented language with multiple > inheritance. Of > course, users don't want the eggs to get cold while the bacon is frying, > so > concurrent processing is required, too." > "We must not forget the user interface. The lever that lowers the food > lacks versatility, and the darkness knob is confusing. Users won't > buy the product unless it has a user-friendly, graphical interface. When > the breakfast cooker is plugged in, users should see a cowboy boot on the > screen. Users click on it, and the message 'Booting UNIX (tm) V8.3' > appears > on the screen. (UNIX 8.3 should be out by the time the product gets to > market). Users can pull down a menu and click on the foods they want to > cook". > "Having made the wise decision of specifying the software first in > the design phase, all that remains is to pick an adequate hardware > platform for the implementation phase. An Intel (tm) 80386 with 8 MB of > memory, > a 30 MB hard disk and a VGA monitor should be sufficient. If you select a > multi-tasking, object-oriented language that supports > multiple-inheritance and has a built-in GUI (graphical user interface), > writing the > program will be a snap. Imagine the difficulty we would have if we had > foolishly allowed a hardware-first design strategy to lock us into a > four-bit microcontroller". > The king had the computer scientist beheaded, and they > all lived happily ever after. > Phil Goodwin wrote: > In the May edition of the C Users Journal Alistair Cockburn published an > article in which he presented the reader with a design problem. While > examining this problem I realized that it has some important similarities > to the Set Top Box problem presented here by Robert Martin. Both problems > have naive solutions which appear to be workable at first, but which reveal > serious flaws on closer examination. The exposure of these flaws leads to > the conclusion that there are requirements of the problem that were not > apparent at the time the problem was first presented (as is often the case > in real-life problems). > > The problem that Cockburn presents is to design a simple Coffee Maker that: > "... serves coffee for 35 cents, with or without sugar and creamer". He > presents, for illustrative purposes, a naive design that consists of: a > Cash box which keeps track of how much money has been put in, makes change > and turns the Front Panel on and off based on how much money has been put > in; a Front Panel which can retrieve a selection from the user and tell the > Mixer what to make; and a Mixer which knows how to talk to a set of five > Dispensers which each dispense one of: cups, coffee powder, water, creamer, > or sugar. Dispensers also know when they are empty. > > This is a fine design for the problem as presented. It is completely > capable of dispensing coffee for the price of 35 cents and adding cream and > sugar as desired. As it turns out, however, the requirements of the Coffee > Machine will change and this design is not robust enough to accommodate the > desired changes without massive rework. This is similar to the Set Top Box > that Robert presented where the screens to be presented needed to be > changed on a regular basis. In both cases the design needs to be robust > enough to allow easy change, and in both cases this robustness was not part > of the original specification. > > Now, changing requirements are nothing new. In fact, we often measure the > quality of our designs against their flexibility in the face of evolving > requirements. What we don't do, however, is to formalize that requirement > in analysis. Where are the use cases for the maintenance engineers? Why is > flexibility given such short shrift during our initial analysis of a > project? Recognizing the need for change is powerful. We could incorporate > it into the Coffee Maker problem like this: "can be modified to: accept > payment from multiple sources, mix and serve new beverages, charge > different prices for different beverages". > > Now we can start to see the changes that are needed to make the design > workable. The first change is easy: we can add a Money Handler between the > Cash Box and the Front Panel that will provide an interface for new sources > of money to interact with. The second and third requirements are a bit more > complicated, they imply the need for a mechanism that will associate the > name of a beverage with its recipe and cost and which will know if any of > the needed ingredients is missing. The word 'recipe' suggests the use of a > language and that is exactly what we will do. This is yet another parallel > to the Set Top Box problem which was solved by creating a browser and > implementing the actual functionality using HTML. Our language will consist > of 'programs' called Orders whose 'instructions' will be called Items. An > Item knows how to talk to a Dispenser and an Order knows how to walk down a > list of Items and 'execute' them in order to fill itself or verify its > availability. In addition an Order knows how much it costs and, for > convenience, knows its own name. > > When we add a new dispenser we can create a new kind of Item which can, in > turn, be combined with other Items to create new Orders. We can make the > Front Panel more flexible by implementing it as a list of Controls. A > Control will know about an Order and can enable itself if the Order can be > filled and the Front Panel reports that enough money is available to cover > the cost of the Order. We can also make a control that knows how to request > refunds from the Money Handler thereby removing that responsibility from > the Cash Box. Now all the Front Panel does is talk to the Money Handler to > find out how much money is available and notify each of the Controls when > this amount changes. > > That, I think, pretty much completes the design of the Coffee Machine. > There are two things that I find striking about this problem as well as the > Set Top Box problem. The first is that specifically acknowledging and > quantifying the need for adaptability during analysis helps to remove the > black-magic aspect of going from analysis to design. The areas where > abstractions need to exist are fairly clear and the language of the > analysis even suggests what the abstractions need to be. The other thing is > that both problems yielded to the approach of using an embedded language to > provide the needed flexibility. If we had built domain models for these > problems I feel confident that the structure and nomenclature of those > models would have been mirrored in the syntax of those languages. I think > that these two insights can help light the road that goes from the > conceptualization of a programming problem to the final design of the > program itself. > > Phil > ------------------------------------------------- > Subscription Requests: majordomo@rational.com - -- regards, David Radnell Adacel Technologies Ltd Phone: +61 3 9596 2991 Fax: +61 3 9596 2960 -------------------------------------------------- Tue Apr 28 11:52:54 METDST 1998 Date: Fri, 24 Apr 1998 19:49:31 -0500 From: "Michael A. Beedle" Subject: (OTUG) Org Patterns Jarek Wilkiewicz wrote: > One has to be careful with any new technology. I know an example of a > Fortune 500 company that tried to use Persistence for a project and it > failed rather miserably. The company has essentially "banned" object > database systems since then (even though Persistence *is not* an ODBMS). > > I guess like with any technology, one has to pick the right tool for the > right job. Worst of all, if an OO project fails, a large percentage of the time it is the technology or the tools that get the blame. Where in fact, it is the incompetence, both at the technical and management levels, which is responsible for most of the failures. In fact of the, ~100 projects or so, that I have either seen directly or monitored from a distance after mid-1992, all of them have failed from HUMAN FACTORS not technology!!! (Before that, since 1986, I have seen a few projects failing from immature tools. But still, most projects failed even then, from OO inexperience and project mismanagement.) For that reason some of us are gathering Organizational Patterns. These patterns are recurring organizational structures of successful software and business organizations. Check them out at: http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ProjectIndex Good OO project management books are densely infested with org patterns. In fact, the last time I read Grady's "Object Solutions", a great book if you haven't read it, I found two or three patterns from the above site in EACH page!! Also, there are a few of us that are working toward unifying all of this org patterns in a Common Pattern Language. This of course, is long term goal that will probably take us a few years to complete. More on this at: http://www.agcs.com/patterns/chiliplop/process.htm I would also like to use this opportunity to invite all of you to participate and contribute writing org patterns. For a couple of good tutorials on patterns, see Brad Appleton's tutorials and introductory papers at: http://www.enteract.com/~bradapp/docs/patterns-nutshell.html http://www.enteract.com/~bradapp/docs/patterns-intro.html Regards, - - Mike Beedle http://www.fti-consulting.com/users/beedlem/