Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!pyramid!athertn!hemlock!mcgregor From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Newsgroups: comp.software-eng Subject: Re: some advice to a software engineer Message-ID: <30690@athertn.Atherton.COM> Date: 21 Sep 90 02:23:09 GMT References: <9009192047.aa05637@PARIS.ICS.UCI.EDU> Sender: news@athertn.Atherton.COM Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor) Organization: Atherton Technology -- Sunnyvale, CA Lines: 103 In article <9009192047.aa05637@PARIS.ICS.UCI.EDU>, nancy@murphy.ICS.UCI.EDU (Nancy Leveson) writes: > I know that it is impossible to provide perfect software. But there is a > difference between putting out the best product we can or one that we feel > meets minimum professional standards and putting out something we know > does not meet those standards. I think that there is frequently a lot of discussion of this, with apparently polarized views, but when real world cases are discussed there is usually unanamous agreement. Nevertheless, discussion of this topic persists. The point of semantic disagreement is typically what is meant by the "best product we can", since the best one can is typically a function of time and resources. Today's automobiles are much safer than automobiles of sixty five years ago. Given enough time and money, many of today's auto safety technologies could have been built as the very first offerings of car companies that existed then. However this situation is knowledgably absurd since the amount of time for development of some of these technologies would then have been in the decades and investors would not wait that long. Moreover, some improvements would not likely to ever have occurred until a large number of users had experience with automobiles, and engineers learned from on-the-road failures. Of course there have also been considerable improvements from year to year in many other technologies, especially electronics: from CD players and video mini-cameras to powerful workstations with megabyte memories. I believe that the same is true for the software industry. However, the pace of new technological change is somewhat faster for the software industry of today than was originally the case for the auto industry (this also accounts for the concern people have for patent's multi-year lifetimes being applied to concepts in the software area). Additionally, current capital gains laws, and other aspects of the US economy often conspire to reduce the payback period that investors are willing to wait for their money. The net result is that "the best one can" may be much more strongly limited by investment money and time to delivery than to the intellectual capability of the developer. One can fight this, with professional regulation, by forcing out companies who can't get sufficient capital and time to market to meet the stronger professional standards. There would probably be less choice in applications, but those that survived would probably be better. There would probably be less opennings for software engineers as well, but those that did find a position would probably be better paid, be more experienced, and be more highly skilled. The rate of change in the industry would probably decrease too as new introductions were more thorougly tested before being released to the public. However, I believe many software users would not want this situation. I believe the reason is that people continue to KNOWINGLY buy imperfect software. I think the reason why is that in many cases software that does many of the right things much of the time (but does some wrong things some of the time), still makes a substantial contribution; one which in fact people would rather have today than wait for a possibly better solution tomorrow.^1 So early (sometimes poorer quality) initial software often succeeds sufficiently to get enough money to fix it. This situation is also furthered by software developer hubris and creeping featurism. One of the reasons why it may not be important that a product has some strong limitations in some areas is that purchasers may not care about those areas, and may only care about the areas that work. Unfortunately, in many cases companies don't really know the needs of the people who will ultimately buy the product as well as they think they will. So some of the effort in adding extra features (and the testing and quality concerns that go along with those features) are wasted. On the other hand where more attention is needed the customer will often willingly suggest improvements. It is not that they engineers couldn't have thought of them in the first place, merely that they couldn't accurately predict all the improvements that could be done that customers wouldn't ever use. (Most customers only use a small subset of the capabilities that the products provide--even the capabilities on their home VCRs). At the same time, since many customers have a limited understanding of what they need until the use a product, there is an advantage to products that have rich marketing checklists, since many consumers will figure that no matter what they need, at least the richest (most checkboxes) product will be good for them. So there is an advantage to the company who builds a product that is "enough useful" that people will 1) use it, and 2) suggest how to improve it. Ironically, in many cases this is a more successful strategy than building the product that people will use but not suggest enhancements to because it is too rich already. The problem is recognizing the dividing line between the two, and also between useful enough and "not useful enough to pay for". After the sales are in the answers are obvious, but predicting them in advance is an art. Note that this preference for early, even if buggy, products is a reflection of market immaturity. "Early adopters" love new things and are willing to put up with some problems to get them. As markets mature, many more people become concerned with "just the same as the Jones" have, but with as good reliability or sex-appeal or whatever as possible. As some of our markets mature, so may the demands for quality without new features. --Scott McGregor ------ ^1 There are some exceptions to this where people have said that they would rather wait than have a half-working solution. IN MANY OF THESE CASES, SELLERS OF EARLY INADEQUATE PRODUCTS HAVE LOST IN THE MARKETPLACE TO MORE RELIABLE VENDORS WHO SHIPPED LATER. But this is the exception; for most software markets, "he who hesitates is lost").