m@Daisy.EE.UND.AC.ZA (06/27/90)
cgregor@hemlock.Atherton.COM (Scott McGregor) Date: 26 Jun 90 02:44:21 GMT Organization: Atherton Technology -- Sunnyvale, CA Message-ID: <25793@athertn.Atherton.COM> Newsgroups: comp.software-eng In article <31097@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes: > The whole problem is that SOFTWARE HOUSES REFUSE TO TREAT > SOFTWARE LIKE ENGINEERING! They try to treat it like production > and manufacturing, and then they cry when deadlines are missed. While I agree that software houses refuse to treat software like engineering, I do not believe that this is why they cry when deadlines are missed. Even other engineering businesses have deadlines and schedules. Accuracy of prediction varies across disciplines and even companies. But people still have them. Companies "cry" when people miss deadlines because the economic consequences of missing them can be threatening to either the individuals or to the organization as a whole. This is as true in engineering as in manufacturing and is a psychological and economic factor, not a scientific or engineering factor. > The point is that "deadlines" are inappropriate in engineering, because > the quality of the product suffers (defective cars, TVs, etc.) You don't run > an engineering firm with that mentality. You don't run a software house > with that mentality, but many do. An engineering firm with a profit only > motive will go out of business after all the structures it designs collapse. > Actually, this is what is happening with a lot of software houses these days. Actually, since much of engineering IS about tradeoffs it is entirely appropriate to consider deadlines in development. Building an elegant product to 80% completion and then abandoning it due to lack of money, or because another company has already nailed down the market is not good just because the quality of the implementation that was completed was high. Success comes only if you survive long enough to deliver your products. Money, manpower and time not being unlimited, you have to meet some constraints to ensure success. Within those constraints it is entirely appropriate to concern oneself about product quality. I also don't doubt that some people paint the constraints as being tighter than they really are, thereby making inappropriate decisions about product quality. But that doesn't mean that one should abandon managing to constraints--it just means you should get more realistic managers. I am loath to make any blanket claims about any class, but in general, many engineering firms go out of business not from too much attention to cash flow and profits, but from too little attention to short term finances to ensure their day to day survival long enough to reach the long term. > I predict "software building blocks" to be a dismal failure, unless one is > happy with resource hog programs. There is too much tuning that a craftsman > can do to double and triple performance in certain situations. Adding "black boxes" > to eliminate this process will guarantee mediocre programs. That is, until we have > 10000 MIPS on every desktop, then maybe "how well" software works will no > longer be an issue. Note that this is already happening. Some machines are getting fast enough that people are accepting resource hog programs that are easy to build and maintain even though more efficient systems are possible. The most obvious cases are 4GLs and spreadsheets that are coded by non-programmers. Higher efficiency programs (in terms of transactions per second, etc.) are possible by trained programmers in languages like assembler and C. But these programs are already "fast enough" for their users, and programmers are not consulted. Additionally, more and more programs are used "off the shelf". Once upon a time almost every company's payroll, Accounts Payable and Accounts Receivables were done with specialized programs suited especially for that company. While this is still true for many large or older companies, most small or new companies now either purchase canned software packages of this sort or subscribe to banking services that use one set of these programs for all their clients. > /.. line of code level... [same as] describing the depth of > /every groove at each point (external interface) and the precise molecule > /by molecule composition of the material. > Every item is accounted for in the building estimate, while every item > IS NOT accounted for in a software estimate. No wonder software > estimates are wrong so much of the time. But then as Scott points out, > you can't complete the whole program just to get the software > estimate. The software business is a tough one to be in. My point is that a succinct description is sufficient to describe an item in a building estimate, but that without standardized components this is not possible in software. If the precise threading depths and widths and nut and bolt lenghts were not standardized, you would have to write a paragraph or two about each one used in the building describing not only these depths and widths and lengths but the tensile strengths of the materials, their thermal properties, etc. If this was done for building, instead of relying on standardized components for which these paragraphs are already written and well-known then detailed design costs would dominate construction costs too, and probably fewer buildings would be done with so many plans (in fact, back when timbers were custom cut and nails were hand made there was less design plans done. Even huge cathedrals were often designed "on the fly" over years and years with different parts of the buildings done differently by different craftsmen. Now some building projects have really immense planning phases that dwarf the complexity of some software projects. However, for those complex building projects we find that the rest of the costs of the project are giant too. I'll bet that if you compare like size building projects to like size software projects (say like being in total man hours to completion of the entire project) you'll find that software design phase consumes a larger amount of the relative budget than the building project does. Increasing this to even larger amount spent on the project to ensure even more precision is often uneconomic for software. > /Moreover, because the engineering costs are small > /compared to the overall construction costs, people are willing to pay for > /a "paper study" > This is true. In a big project, the engineering cost is small compared to > MATERIALS. But the accuracy is good because all the components > are known quantities to estimate. Yes. Now if you are a little less specific, you'll save more on the up front engineering cost, but at increased variability of the production phase. At some point you reach an individual's or organization's balance for predictability vs. cost (the flip side of risk vs. reward). That's what determines what the actual tradeoff is. Unfortunately, largely because of the lack of software components, the specification process is very expensive. So many people trade that off considerable design specificity to achieve lower costs. Granted that comes at some cost in predictability as well. People would like both increased predictability and lower cost. But sometimes the cost factor is the gating factor since if it costs more you might go out of business or at least cancel that investment. In general in the software business today these tradeoffs tend to be toward lower up front costs at the cost of poor predictability. Apparently this common tradeoff is a reasonable one, since companies that do more complete specs are not by and large dominating the industries profits yet. > /However, in Cliff's suggested version.....management has to totally > /commit to a project even before they know what it will cost. > /...[this] shuffles the cost prediction problem to someone else it doesn't solve > /it. > My point is that software is not the business to be in if you want the > accurate cost prediction that occurs in the construction industry. I agree. And I don't think that people are in it for that reason. I think that they are in it because there is some money to be made there and because they think they have the special skills to be successful there. I believe this is true at both the macro and micro levels. Even so, I know that people have different tolerance levels for accuracy and predictability. So within any given organization there is some tension about the precise level of tradeoffs. It is by no means always this way, but I have frequently found that many of the programmers have a lower tolerance for ambiguity than their managers. So while a manager WANTS the same low level of unpredicitability as their engineers, and they may REWARD the more predictable or favorable outcomes, they will be less tense personally about possible variance in the predictions than the engineers. Now this reward structure may tend to aggravate the self-induced tension that engineers have about lack of precision in their estimates, and I suspect that this psychological fact may be the real root of this discussion. > I would rather see software classified as engineering, with no construction > component, and have all software ventures classified as "engineering > studies". Such studies are not fixed-priced, and the accuracy is equal > to the amount of cash you pump in. If you want an accurate estimate, you > PAY FOR IT. Don't do it breaking the backs of programmers who make the > educated guesses, which is all that can be made unless to program is > coded and finished. Programmers are really getting a raw deal in the > current scenario. That's why so many of them change jobs and are > generally disillusioned with their career. I truly believe that no semantic change in whether we classify the work as engineering or construction will make a difference in this matter. As I noted above. The desire for price control and predictability is a basic economic need for survival of the individuals (managers) and organizations in charge. It is also a basic psychological need of the individuals for some sort of stability, purpose, and feeling of control over their future. I do not believe that you can make these psychological needs go away by a change of classification or terminology. I do believe that Cliff is correct that if you want an accurate estimate you have to pay for it. I believe that any competent manager who has done this for a while will recognize that this is necessarily true. But some (and I include myself) will tolerate some amount of unpredictability ("I just want a 'ballpark' figure") in order to save some cost. We don't require absolute accuracy--close is fine. Closer is better, as long as it doesn't cost much. If it costs too much I settle for less accuracy. I try to be humane about this, and let my people know that I understand the level of variance implied (and I take care to consider that when I have to make committments myself). However, I have frequently found that my engineers are personally less willing accept the same level of ambiguity as I am. As I say, I try to be humane about this, but sometimes things do come down to personal differences, I hope that my engineers in the past haven't felt ill-served by this--perahps they will teply and tell me different. I do think that there is one other exacerbating problem, and that is that the ability to predict seems to be in part determined by years of experience. Some people have had many years but don't seem to have been able to convert any of that experience to good use, but there are a many experienced people who give MUCH BETTER estimates and predictions than others. I rarely find inexperienced people who seem to have a talent for good estimates or predictions. This is unfortunate for our profession at present, because so many of the line manager slots are filled with people with only a few years of management experience and often less than ten years programming experience. And so lots of engineers pay for this poor experience of their management, leading to disillusionment, etc. > /The truth of the matter as to how building contractor's can predict > /schedules better than software engineers is that they have a book > /of expected times to do standard tasks. The tasks and materials > /are pretty standardized and have been done by large numbers of > /people so that reasonable maximum times have been observed. > THIS IS THE CORE OF THE ISSUE! > I submit that this will NEVER occur in software because the components > are necessarily different for each program's unique needs. All > buildings are made of the same pieces. Why should we think that > programs in THOUSANDS of industries will ever share many of > the same components? I think the idea is poppycock. Personally, I think that the jury is out on this one. There are still some "custom craft" tasks that don't show up in contractor's books and which are subject to more variation and risk. I think we will always have some custom craft work as Cliff points out. But it is not clear to me that we won't have a growth in components. In some ways I think that we already have, but that you see the benefits most strongly in the end-user systems and applications program areas. I've already mentioned the re-use of accounting software, of spreadsheet macros, of 4GL libraries by end users. We are also seeing standard libraries like Xtk, Motif, even the unix programming libraries that people are adopting and reusing where before they would have written their own window systems, etc. before. Now I (re)used the Xtk widgets a lot, and to the extent I did, I didn't have to worry about variance estimating how long those functions would take to build. Now, there was a case where I needed a widget that wasn't in Xtk, so I had to build it from scratch. It was harder to estimate. That's life. > > /It is different in the software world. ..people ... make > /an estimate without any "book" [to] consult. > / ... tasks...can be more variable. > Exactly what I've said. > > /[distinguish] a schedule (i.e. a contract) and an estimate. > [discussion of inclusion of variances in estimates, scheduling, etc.] > Omission of these items surely contributes to erroneous estimates. > > /For many software projects time to market is > /extremely important. Early entrants often make significantly more > /money than late entrants. > Try a small core of programmers who own enough stock in the company > that they will make a nice nest egg if the product makes it big. Treat > them as an R&D group rather than a production group with > conventional management. I think this will produce more software > of better quality in less time than conventional approaches. Financial > backers of the company won't like this approach though because > if one person leaves, the value of their investment will be diluted. I think that in many cases if you ran this experiment you would see the benefits you claim. But I would attribute it to the fact that you had selected a SMALL group and made the individuals more directly responsible. Because of their economic incentive I would guess that some would take a more personal interest in what the customer wanted too. And those things can lead to more successful products. But if no one paid attention to the costs I would not be surprised if several of these groups ran out of money before completing their projects. And if the host organizations ongoing success was dependent on these projects I would expect some of the host organizations to collapse too. > / So there is the natural pressure (mentioned > /above) to look for optimistic estimates. > YES! I find I always have to match the estimate my manager > suggests, because if I don't I'm in trouble. Actually this > makes estimating easy, except that I am still responsible > when the estimate is wrong. Well, I can understand that. But if you also say "no guts, no glory", what does this imply about the need for "backbone" in setting estimates and schedules that are reasonable? Doesn't "guts" mean taking an unpopular stand sometimes in the hopes that long term rewards will pay off? > Re: Discussion on OOP: > I have yet to see how OOP solves any of the problems regarding > estimating time for writing a program. Someone at some point has > to develop a sequence of steps that make each "object" work. The > subjects I'm discussing aren't even relevant to CAD because using > CAD isn't writing a program - CAD is a higher-level abstraction using > an existing set of modules already written. > The way OOP helps is that it makes the components more standardized and higher level. If you can live with the performance and flexibility trade-offs, OOP means that you will have fewer primitives that you will have to specify. Fewer, more standardized primitives means less detailed and less costly designs relative to the final products. It changes the cost of the paper study relative to the variability in the final product, by reducing the cost of the paper study on a per unit basis. This doesn't mean that specification isn't done, it means that instead of having to specify a page of code you say "displays file name in an XwstaticWidgetClass widget" and you are just as unambiguous. That's less to write, less to read, less possibilities for error in specification, which add up to a less costly specification. Scott McGregor mcgregor@atherton.com --- QM v1.00 * Origin: Bink of an Aye - Portland, OR US - PEP/V32 (1:105/42.0)
willr@ntpdvp1.UUCP (Will Raymond) (06/28/90)
In all the conversations so far, I've yet to see anyone mention learning the task you are trying to program. I am in the end days of a fairly com plex project, writing a "user friendly (!?)" front-end to a DMS10 telephone switch. My shop has a good repetoire of C routines, and we generally use them. In some respects, we assembled the software from off the shelf components. Half the time I've spent on this project ( 1 of 5 programmers spending 28 weeks ) has been learning the switch. The switch is essentially a single purpose computer with 1.8 Megs. of executable written over a 15 year period. Our Technology group produced dozens of conflicting input and output formats for switch commands, the documentation of which encompasses 5 binders and 4,500 pages. 15 years of incremental programming produced many inconsistencies, both in software and documentation. The up shot, adapting our product to the switch took a long time not because we couldn't assemble code from reliable building blocks, but because we had to learn and relearn the task. Will "Because I care...." Dr. Moreau
kandt@ai-jupiter.JPL.NASA.GOV (Kirk Kandt) (06/29/90)
In article <81688@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes: |> In article <8488@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: |> |> ... |> >Various mathematical software libraries are successful because |> >components are reliable and easily identifiable. This same success can |> >be had in other domains too! Someone just has to buy into the high |> >start-up costs in the belief that the long-term benefits are there. |> >Unfortunately, the procurement process of American society does not allow this |> |> It should be noted that mathematicians spent several hundred wall clock years |> and countless man-years exploring the domains in which these libraries work. |> This produced a relatively small yet powerful conceptual basis for these |> domains together with an elegant notation for the concepts. The notation |> was validated in innumerable applications, and the theory was elaborated |> in great detail. Most importantly perhaps, the notation (and the most useful |> part of the theory) was taught to most engineers and scientists. When |> creating these libraries, programmers didn't have to discover the utility |> of log, arctan, eigenvector, etc. Moreover, prospective users already |> know the terminology used to identify and describe components in statistical |> or linear algebra packages, for example. I claim that anything that we build -- a command and control system, a flight reservation system, an operating system, and so on -- has a conceptual basis; if they didn't we couldn't build them. The notation for each of these domains can be described by a language which would provide the syntax, semantics, and even pragmatics for the modeled domain. Individuals can be easily taught this new "notation", it would not be any more difficult to learn than another programming language, or 4GL. |> The lack of a well developed and widely known formal basis for many other |> computing domains may well prove to be a serious impediment to the development |> of reusable software. True, but if a domain is that misunderstood then we are not building implementations of them anyway. I reassert that any artifact that we build can provide components for later reuse. I also assert that if we have built a component we can adequately describe it in a formal or informal notation so that its complete behavior is understandable by a human. I also know that providing such information for later reuse requires much labor at great cost. This is the impediment to software reuse. The issue is "given that you can describe a domain, how do build a information repository in a cost-effective manner." As an example, take the domain of data structures. It is a relatively simple domain. It is well understood. There are both formal and informal methods for describing modeling representations and storage structures. We understand the complexity of them all, including special cases and programming tricks. Yet to date, there is not one reusable data structure depository. Why is that? Because the costs of putting all the knowledge contained in existing data structure books and articles would be incredible. My thesis work was on managing design information for later reuse. I took a couple of toy problems -- the Dutch National Flag algorithm and quicksort -- and described them so that they could be later reused. The amount of information obviously was subjective. But in each case it took approximately 5-10 pages to describe them so that I felt someone else could understand and reliably reuse them. After working on these simple problems I came to the conclusion that the amount of effort required to document complex components would be much greater that the actual construction of said components. As a result, I concluded that software reuse should only be attempted if you are producing the same type of artifact over and over again. For example, if you write 25 Ada compilers for different machines then software reuse is feasible, but if you only write 3 of them then it probably isn't. I also concluded that software reuse as many people envision it is impossible unless some manner of automating the acquisition of information is achieved. If someone is looking for a PhD thesis, here it is. Kirk
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/29/90)
In article <8529@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: ... >I claim that anything that we build -- a command and control system, a >flight reservation system, an operating system, and so on -- has a >conceptual basis; if they didn't we couldn't build them. One must be careful to distinguish between mathematical domain languages and programming languages here. Generally, mathematical domain languages being declarative and nonconstructive are more powerful than programming languages. That makes them useful for concisely expressing precise specifications for software components -- provided you can find a suitable mathematical domain within which to represent a particular software component domain. For example, it might be the case that the reusable components for flight control systems could appropriately be represented in the mathematical theory of partial differential equations, or that those for airline reservation systems could best be described using graph theory. If furthermore, there turned out to be a Find_Flights operation among the airline components which `finds all flights from airport A to airport B of duration less than T leaving on date D', this operation would have a precise graph theoretical specification which would answer any questions about what it would do. Note here that mathematical domains and programming domains differ in that Find_Flights belongs to the latter, but not the former. If by a `conceptual basis' you mean a mathematical domain in which components from a programming domain can be specified exactly, I expect your claim, taken literally, is correct. The real problem, of course, is to find an APPROPRIATE conceptual basis [mathematical domain] for describing components. For example, choosing number theory to describe airline reservation components (using say Godel numbers), while technically quite feasible, would produce totally useless specifications. I presume accordingly that your claim should be interpreted as postulating the existence of appropriate mathematical domains for describing any reusable components that will be created. That seems far from obvious. > The notation >for each of these domains can be described by a language which would >provide the syntax, semantics, and even pragmatics for the modeled >domain. If one did not know how difficult it is to work out the concepts and theory for a new mathematical domain, this could almost be read as suggesting the creation of a theory for each programming domain. > Individuals can be easily taught this new "notation", it would >not be any more difficult to learn than another programming language, or 4GL. Most of us find it fairly challenging to learn a new mathematical domain. It's not, however, the 'notation' of differential equations or category theory that gets to you; it's the insights about the concepts and the theory that takes the time and effort to learn. Unfortunately, a superficial knowledge of a mathematical theory won't suffice for programming. A new age programmer who learned his number theory from a pocket calculator might not know that a program that sums up an array of integers from bottom to top gets the same result as one that sums from top to bottom, even though he understands addition perfectly well at a notational level. /Bill
kpc00@ccc.amdahl.com (Kimball P Collins) (06/30/90)
Will the original "recap so far" poster please contact me? I sent
some email to him and I would like a copy of what I sent to him.
('Twas before I had my mailer save outgoing mail.)
Thanks.
--
Not representing Amdahl nor necessarily myself.andyk@stpstn.UUCP (Andy Klapper) (07/03/90)
In article <8529@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: > >I reassert that any artifact that we build can provide components for >later reuse. I also assert that if we have built a component we can >adequately describe it in a formal or informal notation so that its >complete behavior is understandable by a human. I also know that >providing such information for later reuse requires much labor at great >cost. This is the impediment to software reuse. The issue is "given >that you can describe a domain, how do build a information repository in >a cost-effective manner." > >As an example, take the domain of data structures. It is a relatively >simple domain. It is well understood. There are both formal and >informal methods for describing modeling representations and storage >structures. We understand the complexity of them all, including special >cases and programming tricks. Yet to date, there is not one reusable >data structure depository. Why is that? Because the costs of putting >all the knowledge contained in existing data structure books and >articles would be incredible. > Smalltalk, Objective-C and I would be willing to bet other OOP and OOP like languages, have a set of basic data structure objects (Sets, stacks, ...) including a sorted collection that uses quicksort. It would seem that you have been looking in the wrong place. I agree with you that reuse is hard. It costs much more to write code that is really reusable and nobody gets it right the first time (even if they have written reusable code before *in a different domain*.) The places that I have currently seen the most software reuse (with Objective-C anyway) has been in software shops where the work is clearly defined and vertical (every year they produce a newer version of last year's product (faster, better, stronger ...)) telecommunications, financial, and industrial to name a few. In these shops the software that is reused is their own. In one really big shop 15,000+ classes the sharing of class libraries is across departments. In these environments the 'information repository' problem is partially solved by the fact that the next product team already knows what class libraries they used in the last product they made and how they need to be tuned (subclassed) for the current product. It is also solved by having access to the person who wrote the class so you can ask her 'does this do what I want ?' or 'what does this do ?'. The Japanese are reusing software today, and getting a great deal out of it. I do not think that they have found an easy way of solving your 'information repository' question or my 'how to design for reuse' question. I do think that they place a higher value on reuse and are willing to put the time and effort into it because they feel that they will get a higher return on this higher investment. The numbers that I have seen quoted seem to back this up. 'There ain't no such thing as a free lunch' or 'no pain, no gain' are my favorite quotes on the subject. -- The Stepstone Corporation Andy Klapper 75 Glen Rd. andyk@stepstone.com Sandy Hook, CT 06482 uunet!stpstn!andyk (203) 426-1875 fax (203)270-0106
kandt@ai-jupiter.JPL.NASA.GOV (Kirk Kandt) (07/04/90)
In article <5312@stpstn.UUCP>, andyk@stpstn.UUCP (Andy Klapper) writes: |> In article <8529@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: |> > |> >I reassert that any artifact that we build can provide components for |> >later reuse. I also assert that if we have built a component we can |> >adequately describe it in a formal or informal notation so that its |> >complete behavior is understandable by a human. I also know that |> >providing such information for later reuse requires much labor at great |> >cost. This is the impediment to software reuse. The issue is "given |> >that you can describe a domain, how do build a information repository in |> >a cost-effective manner." |> > |> >As an example, take the domain of data structures. It is a relatively |> >simple domain. It is well understood. There are both formal and |> >informal methods for describing modeling representations and storage |> >structures. We understand the complexity of them all, including special |> >cases and programming tricks. Yet to date, there is not one reusable |> >data structure depository. Why is that? Because the costs of putting |> >all the knowledge contained in existing data structure books and |> >articles would be incredible. |> > |> |> Smalltalk, Objective-C and I would be willing to bet other OOP and OOP |> like languages, have a set of basic data structure objects (Sets, stacks, |> ...) including a sorted collection that uses quicksort. It would seem |> that you have been looking in the wrong place. |> I've used these languages before -- having a basic set of objects is not the issue. The issue is that the implementation of a "type" can be done in a variety of ways, where each implementation has certain advantages and disadvantages in terms of time and space. A set, for example, can be implemented as a bit array, a simple array, a linked list, a hash table, and so on. Smalltalk, Objective-C, etc. generally provide only one implementation of an "abstract type". This one implementation is chosen because it works reasonably well for all cases, but it may not be optimal for a specific data set; in fact, it may be orders of magnitude slower than one tailored for the characteristics of the data set. Automatic data structure selection was a hot topic in the 70s because people realized that there were tremendous pay-offs (in terms of efficiency) by optimizing data storage and manipulation algorithms for the expected data.
news@tut.cis.ohio-state.edu (Usenet News) (07/04/90)
edu> <8529@jpl-devvax.JPL.NASA.GOV> Sender: Reply-To: William F Ogden <ogden@cis.ohio-state.edu> Followup-To: Distribution: Organization: Ohio State University Computer and Information Science Keywords: From: ogden@seal.cis.ohio-state.edu (William F Ogden) Path: seal.cis.ohio-state.edu!ogden In article <8529@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: > .... The issue is "given >that you can describe a domain, how do [you] build a information repository in >a cost-effective manner." > >As an example, take the domain of data structures. ... >My thesis work was on managing design information for later reuse. I >took a couple of toy problems -- the Dutch National Flag algorithm and >quicksort -- and described them so that they could be later reused. The >amount of information obviously was subjective. But in each case it >took approximately 5-10 pages to describe them so that I felt someone >else could understand and reliably reuse them. To a subsequent message about data structure objects in Smalltalk, etc. he writes: >I've used these languages before -- having a basic set of objects is not >the issue. The issue is that the implementation of a "type" can be done >in a variety of ways, where each implementation has certain advantages >and disadvantages in terms of time and space. A set, for example, can >be implemented as a bit array, a simple array, a linked list, a hash >table, and so on. Smalltalk, Objective-C, etc. generally provide only >one implementation of an "abstract type". This one implementation is >chosen because it works reasonably well for all cases, but it may not be >optimal for a specific data set; in fact, it may be orders of magnitude >slower than one tailored for the characteristics of the data set. ... Part of the solution of the problem of `managing design information for later reuse' while still admitting myriad implementations is to recognize commonalities (i.e. seek useful generalizations). For example, when viewed properly, the description of quicksort factors into a portion which is common to all sorting components and a portion that is peculiar to quicksort. This first portion gives a conceptual description of the functionality provided by any sorting facility as well as of the most general types of objects on which it will work. Quicksort, mergesort, heapsort, etc. are then described as realizations for this concept rather than as autonomous entities. The descriptive portion of each such realization of course includes particular realization conventions, correspondences to the general concept, performance specifications, etc. Similarly, one can identify the concept of a general set template which admits array, linked list, hash table, etc. realizations -- each providing the functionality specified by the set template, but differing in performance characteristics. Finding a suitable reusable component then involves first finding the right concept, then finding the realization with the most appropriate performance characteristics. The point is that there are at least an order of magnitude fewer general concepts for facilities than there are useful realizations -- not to mention porcine ones. Moreover, most reusable design information involves the general concepts and not particular realizations, so the concept/realization separation serves well here. /Bill
lgm@cbnewsc.att.com (lawrence.g.mayka) (07/04/90)
In article <5312@stpstn.UUCP> andyk@stpstn.UUCP (Andy Klapper) writes: >Smalltalk, Objective-C and I would be willing to bet other OOP and OOP >like languages, have a set of basic data structure objects (Sets, stacks, >...) including a sorted collection that uses quicksort. It would seem >that you have been looking in the wrong place. Add Common Lisp to the list. Its set of built-in datatypes includes exact rational numbers (with a numerator and denominator, of arbitrary sizes), adjustable arrays, hash tables, conditions (exception objects), generic functions (sets of methods with the same selector), etc. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
lgm@cbnewsc.att.com (lawrence.g.mayka) (07/05/90)
In article <8581@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: >table, and so on. Smalltalk, Objective-C, etc. generally provide only >one implementation of an "abstract type". This one implementation is >chosen because it works reasonably well for all cases, but it may not be >optimal for a specific data set; in fact, it may be orders of magnitude >slower than one tailored for the characteristics of the data set. The Table Management Facility of Symbolics Genera offers automatic data structure selection and mutation within the interface of a Common Lisp hash table. That is, the physical representation of the table - as association list, set, block array, etc. - depends on the characteristics of the currently stored dataset (and on any optional directives and hints supplied by the programmer). Common Lisp itself sometimes offers multiple datatypes for similar purposes (but with differing time/space tradeoffs) - e.g., the representation of a set as either a list, a bit vector, or a binary-coded integer. The choice of datatype must usually, however, be specified explicitly by the programmer. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
andyk@stpstn.UUCP (Andy Klapper) (07/05/90)
In article <8581@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: >I've used these languages before -- having a basic set of objects is not >the issue. The issue is that the implementation of a "type" can be done >in a variety of ways, where each implementation has certain advantages >and disadvantages in terms of time and space. A set, for example, can >be implemented as a bit array, a simple array, a linked list, a hash >table, and so on. Smalltalk, Objective-C, etc. generally provide only >one implementation of an "abstract type". This one implementation is >chosen because it works reasonably well for all cases, but it may not be >optimal for a specific data set; in fact, it may be orders of magnitude >slower than one tailored for the characteristics of the data set. >Automatic data structure selection was a hot topic in the 70s because >people realized that there were tremendous pay-offs (in terms of >efficiency) by optimizing data storage and manipulation algorithms for >the expected data. This is true. I can think of two possible 'solutions', 1) Have 1 class (say Set) that either automatically selects an algorithm based on the data. (Each object in the set would respond to some message, say, optimizeFor, that would return how it wants to be optimized. Above some mixture of requests the class would revert to the basic method (you wouldn't want to de-optimize because 1 out of a hundred objects in the set disagreed over how to optimize).) The other option is to tell the class how to optimize and leave it to the programmer to know what is best. Personally I'd do both, but I always want every option :) 2) Create a number of classes (say of Set), each one optimized in some way. Our ICpak201(TM) product comes with a class called HashSet for exactly the reasons you stated above. The default implementation was too slow because it was designed to given good performance over most cases. The designers of ICpak201(TM) needed a faster set for a limited case. In Brad's world you could buy different Set classes from different venders from a software catalogue and have all of the protocols the same, but the implementation differ. -- The Stepstone Corporation Andy Klapper 75 Glen Rd. andyk@stepstone.com Sandy Hook, CT 06482 uunet!stpstn!andyk (203) 426-1875 fax (203)270-0106
johnson@m.cs.uiuc.edu (07/08/90)
kandt@ai-jupiter.JPL.NASA.GOV said: >Automatic data structure selection was a hot topic in the 70s because >people realized that there were tremendous pay-offs (in terms of >efficiency) by optimizing data storage and manipulation algorithms for >the expected data. Although automatic data structure selection would be nice, it is not really all that important. I program in Smalltalk using sets, sequences, and mappings (i.e. Sets, OrderedCollections, and Dictionaries) and almost never use arrays directly. Once a program works, I profile its performance. Sometimes I find that using a too-general data structure is causing a bottleneck, and I will then rewrite a few classes. However, very few of the uses of the general collection classes are bottlenecks, so it doesn't matter when they are used when a more specialized one could be used. To generalize, arguments against software reuse because it will result in systems that are too slow are wrong. Only the bottlenecks need to be optimized. I save a lot of time reusing components and am happy to spend some of it rewriting working code to make it faster. Another interesting fact is that the standard Collection classes are really fairly efficient, considering what they do. The average programmer who would try to write a linked list routine in C is likely to write something that is slower, and is likely to make a mistake or two. There are a few people who are really good at making programs fast. Once you have a library of reusable components, you should have one of them take a look at it and share their skills with others. Ralph Johnson -- University of Illinois at Urbana-Champaign
cliffhanger@cup.portal.com (Cliff C Heyer) (07/09/90)
My 16K article ended up as a separate collection on my system called "Summary #2". Please see if your system has this collection to read it. I ADDed the article from "article level" as always, but somehow it ended up as a collection.... Cliff
cliffhanger@cup.portal.com (Cliff C Heyer) (07/09/90)
Cliff Heyer, the original poster, responds:
The collection has diverged into sub-topics, the main one being a
discussion of the merits of OOP and OOD.
I FULLY AGREE that OOP has advantages, and will someday yield
benefits beyond what can be had today. But the need to interface with
billions of lines of old code and lack of standards will make this a slow
and painful process. New stand-alone applications will be the
ones to benefit.
I began this collection to establish points of view regarding whether
software be classified as engineering or manufacture (production,
construction, assembly). I asserted that the nature of programming
is inconsistent with the definition of "construction" and therefore
use of the word with software is incorrect.
My observation was that the industry should place emphasis on
classifying software creation as engineering, and replicate the standards
and procedures used by engineering departments/firms as pertaining
to the making of estimates, rather than emulate the practices of the
construction/manufacture industries. I asserted this would benefit
software development by reducing programmer/manager burnout.
I asserted this would benefit software development more than the adoption
of various new metrics such as function point analysis, etc., which
attempt to create an accurate measure of something that is not
measurable in the first place. (Flame me if you want, I can back up
my assertions.)
I don't recall any firm arguments against these assertions, but please
speak up if you are there.
I request comments from persons with hardware engineering
estimation experience for comparison to policies of the software
industry.
[Some of the following comments were lost to another collection,
so I've encapsulated and summarized my points further below.]
==========
It is not correct to say "with software you can separate the design from
the construction phase."
My point is that the "construction phase" is NOT really a construction phase
based on the definition of construction. "Construction" is defined as
"assembly." "Assembly" can only occur when someone has already created
the parts and a plan to combine them (an engineer). With software no one has
BOTH created the parts (functions) AND a plan to assemble them (loops,
conditionals, etc.), so there IS NO ASSEMBLY and THEREFORE THERE IS NO
CONSTRUCTION.
This misconception causes managers to expect more accurate estimates
than are possible, leading to manager/programmer burnout.
With software you are NOT assembling components, you are DEVELOPING new
components and a control structure to surround them. This is engineering.
The terms
***** ARCHITECTURE and ENGINEERING *****
should be used instead of "design" and "construction" respectively. Software
estimates should be made the same way hardware engineers make their
estimates.
Lets discuss hardware estimates.
Do such estimates allot a fixed amount of time for each chip to estimate
a board design? (eg. 80386 = 2 weeks, etc.)
==========
Engineering deadlines are by default flexible. You can't market a TV
that does not work, right? Therefore the deadline gets moved whether anyone
likes it or not. And I see evidence that those engineers are not pressured to the
same degree as programmers. Management knows that pressure = errors =
delayed completion = increased costs. (But then you have to weed out loafers
who take advantage of a non-production environment to not produce.)
==========
It is NEVER right to design a software system ONLY on paper for the purpose
of devising an estimate, unless you can be happy with an estimate that may
be way off.
Such estimates are bound to be useless because numerous coding difficulty
assumptions will be wrong without support of actual time measurements.
These errors propagate in an exponential manner throughout layers of code.
The best that can be hoped for is a "estimate as you code" procedure where you
use actual experience on the project to gauge the completion. From my
experience, I can predict to the week the completion of certain projects after
completing only 20% of the project. The paper estimates at the start
NEVER correlate to the actual time.
==========
John Dudeck writes....
>A lot of what is gained in OOD is in the de-sequentializing of our problems.
How does de-sequentializing happen?? Not because of the "magic" of OOP.
Old command line interfaces had HUGE amounts of code to tokenize strings and
then conditionals to figure out the command before executing the appropriate
subroutines. STATE TABLES and related code were huge.
All OOP has done is remove this layer, by having the user do the "IF" and
"TOKENIZE" by pointing to what he wants and clicking the mouse. In other
words, instead of using the computer to figure out the command we let
the user tell the computer the command by pointing to it and clicking.
No magic here, just the expected result of a change in hardware/
software architecture.
So I agree the de-sequentializing occurs, and this is one of the exciting
things to me about OOP. But I can't give OOP the credit for it. It's
a result of the MOUSE.
==========
Perhaps component reuse is one place where the federal government CAN help.
I'm thinking of how AM STEREO got messed up because the government
didn't come in and standardize. Now we have three or so types of
AM stereo and much more complicated decoder chips in the radios
to detect and decode each kind.
COLOR TV's introduction was smooth because of the decision to
support one format.
What if the FCC begins to regulate local area networks like they
regulate the phone system, and proclaimed X-Windows to be the
standard?
Perhaps we could get on with life and do bigger and better things
rather than waste man hours creating dozens of different GUIs?
(eg. X, Windows, Presentation Manager, MacOS, etc.)
==========
Because software only requires thought to create, often it
takes LESS THOUGHT to MAKE a component yourself than to LEARN
to re-use an existing one.
This is a strong obstacle to component re-use. A managerial
directive must be enforced, but this may conflict with
"time to market".
==========
We have to look at how people get satisfaction in their work. If a programmer
gets satisfaction from "using his own code" then obviously he will always
resist using components. The activities by which a person gets satisfaction
can directly contradict the activities needed to produce acceptable work.
(eg. drug addiction an extreme example). The need for a manager who is
sensitive to and can interdict destructive satisfaction-getting cannot
be overstressed. The same problem can occur with managers, for example,
if a manager gets satisfaction from saying humiliating things to subordinates.
==========
Edward J. Prochak writes....
>My bottomline point is that tuning
> may not require change source code.
>It may just as likely involve swapping
>one object with a similar one having
>different performance attributes that
>better match the application.
>
>Does this sound close to being in the ballpark?
YES! But this is a long ways off! I can't fathom the
task of trying to standardize components, and then growing
to a level of sophistication where we could choose different
flavors of the same components. And doing all this trying to
interface with billions of lines of code written the "old fashioned
way."
Clearly there is a route to the future here. But we are not there
now, and these concepts don't solve today's problems. It is the
job of the academicians to lead us to this "Garden of Eden" for future
generations.
==========
>Consider the lowly cash register. Most people (that can include us
>software types) don't think much about such commodities,....
> Do we or the store owner or almost anyone else
>care if the code inside is structured or spaghetti or in assembler or
>COBOL (yes, there are cash registers running COBOL) as long as the right
>barcode gives the right price and it doesn't bill the wrong amount to
>our credit cards?
This shows how UNimportant ELEGANCE of code can be! I'm not a
proponent of elegant code. I'm a proponent of code that gives the
user an adequate level of performance and functionality. This is
why I think software paper designs can only be a small part
of the design effort. You can only *with accuracy and certainty*
establish performance and functionality"by using the ACTUAL
PRODUCT, not a paper design.
You can't gauge the speed and "feel" - that will give you competitive
advantage - until you've completed a portion of your product. THEN
you'll know if your design is worth a hill of beans or not.
I am angered by people who confuse "excessive elegance" with "acceptable
performance and functionality." CORRECTNESS cannot be compromised!
Cliff Heyerjohn@iti.org (John Sauter) (07/10/90)
In article <31558@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >The terms > > ***** ARCHITECTURE and ENGINEERING ***** > >should be used instead of "design" and "construction" respectively. I don't necessarily agree that the distinction in terms is that important. A hardware engineer works with specifications and models. His work can easily be described as "constructing a model" whereas the construction worker is responsible for "constructing the real object". They both work with standard building blocks, the engineer's building block primarily being intangible objects used to build models (model used in the more generic sense, not enough room to define here). Software is such an intangible thing. What is the final product? Is it the binary representation of the program as it is encoded on a magnetic media embodied in a piece of computer hardware? Or is it a pattern of charges in electronic gates on a circuit board after it has been copied from disk? What is involved in the construction of the final end product of software. To my knowledge it is mostly done automatically and therefore is of little interest to software engineering (except to those how build compilers, linkers, disk drivers, etc.). If this is the case then software engineering is primarily concerned with building models and therefore can best be seen as an engineering discipline. Even after reaching this conclusion I don't think I'm any further ahead in approaching this problem! >Software >estimates should be made the same way hardware engineers make their >estimates. > >Lets discuss hardware estimates. >Do such estimates allot a fixed amount of time for each chip to estimate >a board design? (eg. 80386 = 2 weeks, etc.) >========== >Engineering deadlines are by default flexible. You can't market a TV >that does not work, right? Therefore the deadline gets moved whether anyone >likes it or not. And I see evidence that those engineers are not pressured to the >same degree as programmers. Management knows that pressure = errors = >delayed completion = increased costs. (But then you have to weed out loafers >who take advantage of a non-production environment to not produce.) >========== I don't think that hardware engineering works this way. Talking to my HW engineering friends I find that they are faced with deadlines and schedules just like I am. Do you think GM is going to delay a new product introduction 6 months because some engineer ran into a design problem? If there is a problem anywhere, they throw people at it and resources until it is solved. If that fails they always have something to fall back on: use last year's design. In any case there is sufficient differences between the realm of HW engineering and SW engineering that has been discussed at length here. I don't believe we will find a solution to our problems from the HW engineers (except in understanding the need for rigor, structure and discipline as we have better tools and techniques to work with). >This is a strong obstacle to component re-use. A managerial >directive must be enforced, but this may conflict with >"time to market". >========== >We have to look at how people get satisfaction in their work. If a programmer >gets satisfaction from "using his own code" then obviously he will always >resist using components. I agree that reuse is hard. There are technical problems (such as cataloging for retrieval, finding what you need) and social problems (NIH on the individual level). I think the social problems are the most difficult to solve. Even the comments in this group from people actively reusing components tend to emphasize one of two catagories of software reused: 1) software written by the same person who is reusing it (the programmer who builds up a huge library of reuseable modules) 2) software that solves an "uninteresting" problem from the perspective of the person whi is reusing it. The second kind is a little more subtle. I am more likely to use a library component if it solves a problem I am not personally interested in solving. I find DBMS problems B*O*R*I*N*G! I will gladly buy, reuse anyone's code so long as it performs reasonably close to my requirements. However give me a "standard" linked list management package and I am very tempted to write my own, optimized to managing just the kind of lists I need for my project. Every time I look at a standard package I see all the extra baggage needed to support generality which I consider to be non-essential. Perhaps this is due to my "poor" upbringing. I was raised and nurtured on 6502's and Z-80's in the late 70's and spent many hours squeezing everything I could out of those puny processors with tight assembly language code in order to do the kinds of things I needed (real-time control). Now when I look at excess code my frugal upbringing rebels inside of me. Perhaps I should be put out to pasture and younger programmers who have been raised on the fat of 40MHz 68030's and RISC machines which you never touch with an assembler should take over. Perhaps these will be less likely to fall to that kind of temptation. But I suspect that even these will have their weak spots and category #2 will always haunt us. >Edward J. Prochak writes.... >>My bottomline point is that tuning >> may not require change source code. >>It may just as likely involve swapping >>one object with a similar one having >>different performance attributes that >>better match the application. >> >>Does this sound close to being in the ballpark? >YES! But this is a long ways off! I can't fathom the >task of trying to standardize components, and then growing >to a level of sophistication where we could choose different >flavors of the same components. And doing all this trying to >interface with billions of lines of code written the "old fashioned >way." I agree. There is a marketing problem here. Just to market a single version of a reasonably complete set of objects for a single programming domain (say GUI's or DBMS) requires an immense number of objects. Just browse through the Smalltalk classes for an example. You could spend several man-months (even a man-year) just trying to understand all that is in there. To suggest that we could have several versions of each of those classes/objects begins to exceed any human capability to successfully market and use that number of objects. The best approach is stil the availability of source code for modification, but alas we run into a greater business problem with that approach. >You can't gauge the speed and "feel" - that will give you competitive >advantage - until you've completed a portion of your product. THEN >you'll know if your design is worth a hill of beans or not. AMEN! That's why I think rapid prototyping is one of the best things going in software engineering. -- John A. Sauter Industrial Technology Institute Internet: john@iti.org PO Box 1485 Ann Arbor, MI 48106
rh@smds.UUCP (Richard Harter) (07/11/90)
In article <39400111@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu writes: > To generalize, arguments against software reuse because it will result > in systems that are too slow are wrong. Only the bottlenecks need to > be optimized. I save a lot of time reusing components and am happy to > spend some of it rewriting working code to make it faster. There is much to this statement, but there are also some major qualifications. First of all, as we all know (or do we?) the single most likely reason for slowness is the choice of the wrong algorithm in the wrong place. This is a major topic in its own right. The "right" alogorithm quite often not the one with the asymptotic behaviour. Given that we have the "right" algorithms, where does slowness in software arise and what are the possible gains? Let us take a "typical" program and look at optimising it. We gather our profilers and performance analysis tools and study the hell out of the software. What do we find? The first cut shows us the bottlenecks. In a typical program you find that 80% of the execution time is spent in a handful of routines. What you do then is two things: (a) you optimize the individual routines, and (b) you reduce the number of calls to those routines. The latter is usually more profitable. Let us assume that we have done our job well. We then have an execution profile that is fairly flat. Are we done? No. We now have to deal with the layering effect. A simple, extreme example of this is code that is run on an emulator. We can optimize the hell out of the code but we are not touching the major source of inefficiency, which is the invisible layer comprising the emulator. Ordinary programs do not have this problem; however ordinary programs are often built in layers. Each layer extracts its own toll in overhead. Moreover this toll is not easily spotted or analyzed with ordinary profiling tools. One can be nibbled to death by ducks as well as eaten by man-eating tigers. > Another interesting fact is that the standard Collection classes are > really fairly efficient, considering what they do. The average programmer > who would try to write a linked list routine in C is likely to write > something that is slower, and is likely to make a mistake or two. There > are a few people who are really good at making programs fast. Once you > have a library of reusable components, you should have one of them take > a look at it and share their skills with others. Yes and no. It is my observation that the quality of publicly available (standard) code is not all that it could be, although it is quite often better than that of "the average programmer". Reusable code of any sort is written by someone. That someone always has constraints on the amount of time and effort they can spend on the code. Optimization is expensive in terms of human hours. It is also expensive in terms of talent. As Ralph remarks, there are few people who are really good at making programs fast. And then there is the question of "Is increased speed worth the effort necessary to achieve it?" It all depends. My estimate is that the average program of size can be speeded up by a factor of 2-10 times. That seems drastic (and surely worthwhile.) However the next generation of machines is always cheaper than the current round of optimization. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (07/12/90)
In an article rh@smds.UUCP (Richard Harter) wrote: >We now have to deal with the layering effect... >...ordinary programs are often built in >layers. Each layer extracts its own toll in overhead. Moreover this >toll is not easily spotted or analyzed with ordinary profiling tools. >One can be nibbled to death by ducks as well as eaten by man-eating tigers. What you call the "layering effect" is a negative aspect of what is the otherwise highly desirable goal of decomposition of a problem into cohesive, loosely-coupled chunks. The more we can increase the independence, generality, and ultimately the reusability of our code, the more advantages we gain in terms of programmer efficiency on the long term, maintainability, etc. On the other hand, each layer of abstraction involves adding a layer of indirection to the code. >And then there is the question of "Is increased speed worth the effort >necessary to achieve it?" It all depends. My estimate is that the average >program of size can be speeded up by a factor of 2-10 times. That seems >drastic (and surely worthwhile.) However the next generation of machines ^^^^^^^^^^^^^^^^^ >is always cheaper than the current round of optimization. Creating software that meets the users needs, is robust and maintainable, and is delivered in a timely manner is worth the overhead of the ineffeciencies that may be incurred by reuse. Of course if the *user's needs* include requirements for response time, throughput, or other efficiency-related factors, and if the reuse of code doesn't allow those requirements to be met, then there is reason to address the issue. However, when the requirements are met, it isn't correct to say that it is "surely worthwhile" to hand-optimize a design at the expense of destroying the abstractions that permit code to be reused. This brings up the importance of the compiler in being able to do global optimizations. This is what is going to save us in the end. We need to be able to program at a high level of abstraction, and let the compiler figure out how to make an efficient executable out of it. I think rather than bashing the concepts that promise a solution to our most pressing problems, we should be working towards perfecting the techniques that will let our machines effectively put these concepts into practice :^) -- John Dudeck "I always ask them, How well do jdudeck@Polyslo.CalPoly.Edu you want it tested?" ESL: 62013975 Tel: 805-545-9549 -- D. Stearns
cliffhanger@cup.portal.com (Cliff C Heyer) (07/15/90)
John A. Sauter writes... >>The terms >> >> ***** ARCHITECTURE and ENGINEERING ***** >> >>should be used instead of "design" and "construction" respectively. > >I don't necessarily agree that the distinction in terms is that >important. A hardware engineer works with specifications and models. >His work can easily be described as "constructing a model" You have COMPLETELY missed my point. This is not the same use of "construction" as I used. I was using "construction" in the context of an "assembly line". What you speak of is a PROTOTYPE. Engineers routinely build prototypes. This is not like the work a contractor does. A contractor has a set of components that an engineer has already chosen and a plan (blueprint) where an engineer has determined HOW to fit the components together. This is nothing like what an engineer does with a prototype. The engineer has NOT yet selected the components, that is what is job is. He has no plan for assembly, his job is to determine that. As he does his job, he builds a prototype. >whereas the construction worker is responsible for "constructing >the real object". True, but this has nothing to do with my point. >They both work with standard building blocks, the engineer's >building block primarily being intangible objects used to build models >(model used in the more generic sense, not enough room to define here). But HOW they work with them is different. Just because I hold a $100 bill, do I say I am like Donald Trump? >Software is such an intangible thing. ...with building models and therefore >can best be seen as an engineering discipline. Yes. There is no "construction" (contractor) phase because all you have to do is copy the software to a new disk. The prototype or model IS your end product. With other engineering fields, you take the prototype or model and build an assembly line or hire a contractor (construction). >Even after reaching this conclusion I don't think I'm any further ahead in >approaching this problem! You're farther along than you think! >Talking to >my HW engineering friends I find that they are faced with deadlines >and schedules just like I am. I think we have to make another distinction here of some engineering being "production" in nature. That is, every year GM makes a car that is similar to 1000's of previous cars. There is already a "book of standard times" that describes how long it takes to engineer a car. If something can't be done, they revert to last year's design (that did work.) When I discussed HW engineering I was referring to engineers creating something "new" such as the first electronic watch. NOT the 1000th electronic watch. There IS a difference!! After engineering thousands of cars, GM has a pretty good idea how long it takes to engineer a car. With software, there is no such situation. A software firm such as Ashton-Tate or anyone else does not make 100% new dBase every year from scratch. There is no history to estimate by as with cars. Each project is like the first electronic watch. >Do you think GM is going to delay a >new product introduction 6 months because some engineer ran into a >design problem? ... throw people at ... If that fails they always >have something to fall back on: use last year's design. This is a luxury that software engineers don't have, because they don't have such a long history (90 years) of engineering to go by. >In any case >there is sufficient differences between the realm of HW engineering >and SW engineering that has been discussed at length here. I don't >believe we will find a solution to our problems from the HW >engineers (except in understanding the need for rigor, structure >and discipline as we have better tools and techniques to work with). With your description of GM, yes. But again, I was speaking of engineering where management has no prior experience to gauge by. (eg. the creation of the first oxygen sensor). >I agree that reuse is hard. There are technical problems (such as >cataloging for retrieval, finding what you need) and social problems >(NIH on the individual level). The conclusions I have come to so far is that engineering that has been done before many times can be somewhat estimated, but not to the degree of accuracy as a contractor's standard book of times, because the development component of engineering is not fixed. I asserted software creation is engineering and the development component means we cannot ever expect accurate estimates. >I think the social problems are the >most difficult to solve. Software has not evolved to the point where anyone can agree on what standard components should be created. The situation is that many programmers take pride (get satisfaction from) in devising their "own" way of doing things. This is because software is unique in that we can create components ourselves, rather than needing specialized manufacturing equipment. This fact will make software harder to standardize than probably anything in the past. >I am more likely to use >a library component if it solves a problem I am not personally >interested in solving. Exactly. Part of the fun of programming is the programmer has the freedom to try different things and please himself. Take this away, and probably half the programmers won't want to be programmers any more. >Every >time I look at a standard package I see all the extra baggage needed >to support generality which I consider to be non-essential. Perhaps >this is due to my "poor" upbringing. I was raised and nurtured on >6502's and Z-80's in the late 70's and spent many hours squeezing >everything I could out of those puny processors with tight assembly >language code in order to do the kinds of things I needed (real-time >control). SO WAS I!!!! The only thing is, THIS HAS NOT CHANGED!! With MS-DOS we still have the 640KB limit. I routinely do assembler and save 20-60KB here and there replacing C library routines. On a 386, you can feel the difference - the assembler makes a program cook compared to doing things in C. The C compiler generates such verbose assembler that many times it's a joke. Whether you're talking about Windows, OS/2 or UNIX, assembler still makes a HUGE difference! >Perhaps I should be put out to pasture and younger >programmers who have been raised on the fat of 40MHz 68030's and >RISC machines which you never touch with an assembler should take >over. As far as I'm concerned, a programmer that does not know assembler is not a programmer if performance is a concern. I can spot code written by a computer scientist w/o assembler knowledge in a second. They don't understand how to code to save machine cycles. ++++++++++++++++++ I'd like to comment on a previous poster's comments regarding the making of guns during the Civil War. At the time, the industry was resisting the introduction of standardized components in gun manufacturing. This is NOT like the current OOP dilemma. The gun problem dealt with converting from custom piece fabrication to assembly line. There is no "assembly" phase to programming. Gun makers were making custom guns piece by piece, just as if one made a prototype car over and over again. Obviously this would be an extremely expensive way to make a car, a gun, or anything. So some wise chap realized that each of the components could be stamped out by a machine, and then assembled, thus saving much time and money. This analogy suffers from the same error I have been discussing from the start - that is people mistake programming for assembly. I say again, IT IS NOT! Assembly assumes that an engineer has already selected the components and devised a procedure for assembling them. Programming IS the process of selecting components, and CREATING components, and then devising a way to assemble them (glue logic). OOP will fail to produce component-based software manufacture because there is no "manufacture" component to programming. Engineering can't be automated, until we have computers that are just like people. +++++++++++++++++ >Just browse through the Smalltalk classes for an example. You could >spend several man-months (even a man-year) just trying to understand >all that is in there. And once you select them, you still have to program to make them work; hence there is no "assembly". It is often cheaper to just write non-portable code than to figure out the objects to use them! John Dudeck writes: >This brings up the importance of the compiler in being able to do global >optimizations. This is what is going to save us in the end. Well we have a long way to go. With my knowledge of assembly language I looked into what "optimizers" really do, and came to the conclusion that all they do is remove code that "good" programmers don't use in the first place. In other words, if a programmer really understands how a processor works, he will write code that the optimizer can't optimize (except for removal of stack probes, etc.). I could only conlude that an optimizer is a band-aid for bad programming. >What you call the "layering effect" is a negative aspect of what is the >otherwise highly desirable goal of decomposition of a problem into >cohesive, loosely-coupled chunks. The more we can increase the >the more advantages we gain in terms of programmer efficiency on the >long term, maintainability, etc. On the other hand, each layer of >abstraction involves adding a layer of indirection to the code. I think layers=problems sometimes too. In C on my 386, whenever I use the debugger to see what the code does, I note a typical user call to a Microsoft library function results in about 20 calls to lower and lower level routines, until finally you get to the assembler instruction/BIOS call that does the work. I replace these 10,000 lines of library assembler with a 100 lines I code myself, I reduce my executable by 20KB and my program cooks. I remove all those layers of conditionals and go right to the low levels and do what needs to be done. >Creating software that meets the users needs, is robust and >maintainable, and is delivered in a timely manner is worth the overhead >of the ineffeciencies that may be incurred by reuse. This is true!!! Cliff
rh@smds.UUCP (Richard Harter) (07/16/90)
In article <269b7b9d.5643@petunia.CalPoly.EDU>, jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > What you call the "layering effect" is a negative aspect of what is the > otherwise highly desirable goal of decomposition of a problem into > cohesive, loosely-coupled chunks. The more we can increase the > independence, generality, and ultimately the reusability of our code, > the more advantages we gain in terms of programmer efficiency on the > long term, maintainability, etc. On the other hand, each layer of > abstraction involves adding a layer of indirection to the code. One can scarcely argue with your list of goals. However the whole matter is not exactly as simple as it seems. Barring the occasional circumstance where one is "programming down to the bare iron" we are using packages and facilities that are pre-existent all of the time. We use OS calls and facilities. We write in languages that are compiled and interpreted. We use routines from libraries (and pre-defined classes, etc.) None of these facilities and abstractions were created with our particular problems in mind. Sometimes the fit is good; sometimes people create the most Godawful kludges using off the shelf components. I guess all that says that is that people can write bad programs regardless of the languages and tools available. However I would like to make the point that efficiency and "good programming" are not antonyms. One can usually have your cake and eat it too. The only problem is that there is a price for doing it. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
ogden@seal.cis.ohio-state.edu (William F Ogden) (07/17/90)
Cliff writes: ... >>Software is such an intangible thing. ...with building models and therefore >>can best be seen as an engineering discipline. >Yes. There is no "construction" (contractor) phase because all you have >to do is copy the software to a new disk. The prototype or model IS your >end product. With other engineering fields, you take the prototype or >model and build an assembly line or hire a contractor (construction). The ability to ship a prototype as a finished product is one of the curses of our field. Imagine where other engineering disciplines [and society] would be if it were possible to clone a breadboard or a prototype car at a cost comparable to that of turning out a production engineered version. A lot of quality is usually added to a product during production engineering. Similarly, fixed price contracting (i.e. non-government :-) creates a certain quality control on architectural and civil enginering products. No contractor is going to bid on a project unless the design product is demonstrably well thought out. Nobody has a comparable concern with the internal details of software. /Bill
mcgregor@hemlock.Atherton.COM (Scott McGregor) (07/17/90)
In article <1990Jul10.134226.22459@iti.org>, john@iti.org (John Sauter) writes: > >Engineering deadlines are by default flexible. You can't market a TV > >that does not work, right? Therefore the deadline gets moved whether anyone > >likes it or not. And I see evidence that those engineers are not pressured to the > >same degree as programmers. Management knows that pressure = errors = > >delayed completion = increased costs. (But then you have to weed out loafers > >who take advantage of a non-production environment to not produce.) > >========== > I don't think that hardware engineering works this way. Talking to > my HW engineering friends I find that they are faced with deadlines > and schedules just like I am. Do you think GM is going to delay a > new product introduction 6 months because some engineer ran into a > design problem? If there is a problem anywhere, they throw people at > it and resources until it is solved. If that fails they always > have something to fall back on: use last year's design. In any case > there is sufficient differences between the realm of HW engineering > and SW engineering that has been discussed at length here. I don't > believe we will find a solution to our problems from the HW > engineers (except in understanding the need for rigor, structure > and discipline as we have better tools and techniques to work with). I think that John is correct. In all disciplines management views their job as making tradeoffs between time, quality and functionality. This is as true in hardware as software. These three define an triangle whose area is determined by resources applied, any two of the three can be changed and the area still kept with constant resources. Management can manage the slow progression to a particular configuration by the application of resources and the emphasis of particular goals. Because the area also represents VALUE to the customer there is always pressure to get as large an area as possible with the smallest amount of resources. This ratio represents EFFICIENCY of production. In general, management of software does want solid schedules. I find that engineers often internalize their own goals and are less flexible in changing functionality and quality than management might be. I believe that this is a social aspect. Engineers don't like to shave functionality because it is the thing that they want to do--that's why they entered the trade. Engineers don't like to shave quality because of self-integrity, they want to feel they did a good job by their own internal measures. Time frames are typically less important to software engineers, so they would feel better sliding the schedule and holding the other aspects constant. Since managers often get measured on what ships and not how much work was done, their is a social opposition here. I believe these are the reasons why we see tension between software developers and their managers on "unreasonable schedules". Note, these are definately observations about large groups of people, and may not be true of all people who are developers or managers. I just note a propensity in terms of differing personal and institution reward structures that lead to potential conflict over this issue. engineer > I agree. There is a marketing problem here. Just to market a single > version of a reasonably complete set of objects for a single programming > domain (say GUI's or DBMS) requires an immense number of objects. > Just browse through the Smalltalk classes for an example. You could > spend several man-months (even a man-year) just trying to understand > all that is in there. To suggest that we could have several versions > of each of those classes/objects begins to exceed any human capability > to successfully market and use that number of objects. The best > approach is stil the availability of source code for modification, but > alas we run into a greater business problem with that approach. This may be a false problem. There are already many more hardware devices in catalogs than most people can learn about and remember. People don't. They only remember a subset that proved useful in the past, and maybe ask others around them. They only bother to keep up with a few new products each month and maybe incorporate them. Products that aren't widely used often go out of production. And people often don't develop the "optimal" board because the possible permutation set is huge. Instead, they build the best "satisfactory" board that they can given their current knowledge set. Some companies, and some individuals then get an advantage because their designers know something about an important class of tools that competitors don't. They make better designs and this makes them more valuable (more profitable). But they never really reach optimum and their are always opportunities for further improvement that competitors can exploit. Even in software, it is typical in rich languages such as PL/I, or editors such as EMACS, that people only master a sufficient subset of the possible commands in order to solve their problems. People with a richer subset, or a subset in the right area can have an advantage over others. Scott McGregor mcgregor@atherton.com
eachus@linus.mitre.org (Robert I. Eachus) (07/18/90)
In article <27199@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes:
In general, management of software does want solid schedules. I find
that engineers often internalize their own goals and are less
flexible in changing functionality and quality than management might be.
I believe that this is a social aspect. Engineers don't like to shave
functionality because it is the thing that they want to do--that's why
they entered the trade. Engineers don't like to shave quality because
of self-integrity, they want to feel they did a good job by their own
internal measures. Time frames are typically less important to software
engineers, so they would feel better sliding the schedule and holding the
other aspects constant...
The problem with this (management) point of view is that it is
often wrong in the software arena. A manager may not like the fact
that Widget 4.0 still isn't shipping because of major bugs, but once
you have reached that point you only have two ethical choices: Cancel
the project, or keep looking for the bugs. The fact that a less
ambitious revision would have shipped on time, or that the changes to
add feature X probably caused the problem is now irrelevant. Taking
out the mods will only make the final relase later.
The analogy that I like to use is of building a house. Before
the builder gets beyond the first floor it is still possible to
redesign to leave the third floor out. It may not save as much money
as you hoped but... However, futher down the road, there is no choice.
You can't leave off the roof and still have a house to sell.
Another related phenomena is that the "true" quality metrics for
software are almost always Boolean. People will buy a program which
gets the right answer 90% of the time, but only if they don't know
what they are getting. Deliver an accounting package to a bank that
almost always gets the balance correct, and the bank will be willing
to discuss fixes with you--in court.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...mcgregor@hemlock.Atherton.COM (Scott McGregor) (07/18/90)
Some further comments concerning Cliff's recap. In general I agree with the facts that Cliff records. I have some differing interpretations of what should be deduced from them. Cliff writes that software engineering prediction models >... attempt to create an accurate measure of something that is not > measurable in the first place. Software development time is surely measurable. We measure it after the fact every time we ship a product. At best what Cliff is saying is that they attempt to give an accurate PREDICTION of something that is not PREDICTABLE in the first place. This is more correct, but truthfully everyone who builds tools for predictions of this sort is usually quite upfront about the fact that they create predictions of MEANS with some VARIANCE. Often, the tools will either show you the variance, or if you consult the original research data on which the tool was built you can get the underlying measures of variance. As Cliff points out these levels of variance are extremely high. In that sense you won't get a very accurate prediction. However, the say that the tools attempt to give an accurate prediction is overstating things. The tools attempt to merely give the MOST accurate prediction possible, admitting that this prediction is not very dependable. It may not be accurate, but it is a better prediction than one might arrive at with no data. Clearly, software schedules are predicted by people, and so ipso facto are predictable, it is merely that the predictions may not be very accurate. > Such estimates are bound to be useless because numerous coding difficulty > assumptions will be wrong without support of actual time measurements. > These errors propogate in an exponential manner throughout layers of code. Cliff correctly identifies a chief source of the lack of accuracy. Software, like other chaotic dynamics processes, seems sensitively dependent on such specific initial starting conditions that it is inherently impossible to predict future states with certainty. However, his characterization of such estimates as useless is an overstatement. In the game of blackjack (21), the odds can be calculated concerning successful draws if you hand contains 13 points, 15 points, 19 points, etc. When you know the odds, you do not know accurately what the outcome of the next draw will be. But knowing (and playing) the odds can be better than ignoring them in the long run. The odds aren't useless merely because they don't offer certainty for each draw. Card counters, can do even better because they have more accurately odds estimates, but they don't have better certainty over the next particular draw. So there is even value to more accurate estimates, even when you still have lots of room for error. > It is NEVER right to design a software system ONLY on paper for the purpose > of devising an estimate, unless you can be happy with an estimate that > may be way off. The point is that some people can be MORE happy with an estimate that is LESS way off, even if it still is far from perfect. The alternative, NO estimate, is often psychological unacceptable to risk averse persons. They might not like the amount of variance in the current estimate; they might want more certainty, but some estimate is better than none. > Lets discuss hardware estimates. > Do such estimates allot a fixed amount of time for each chip to > to estimate a board design (eg 80386 = 2 weeks, etc.) I have created and maintained support systems for HW designers. The answer, is that in a manner of speaking they DO make estimates based on numbers of elements. IC designers frequently composed their designs by putting together numbers of pre-defined elements: so many gate-arrays of a certain sort, some I/O buffers, so many registers, an arithmetic unit that does such and such. Board level designers would then say so many RAMs, a such and such CPU, this sort of I/O processor, a memory manager, floating point chip etc. System designers would design with thus and so bus, a motherboard, various I/O and memory boards, etc. First estimates for how long these projects would take were often derived merely from the total numbers of elements to be used at any given level. Hardware design estimates, especially early ones, were often inaccurate. But, just as software estimates, they improved as more of the project was completed. However, I believe that the hardware designers had an advantage, and that this advantage yielded some important reduction in variances. In general, the amount of a complexity on a chip is roughly about the same as the amount of complexity of another chip of the same type in the same era. Similarly with boards and systems. Also interestingly, the amount of complexity on a board is typically not much more complex than the underlying chip if you treat each component on the board as a black box the way you might treat a gate on a chip as a black box. And it is not easy to visually confuse a chip, a board and a system. Software components on the other hand tend to vary greatly in internal complexity, in ways that are not at all apparent from their external interfaces. Thus if you are making estimates about complexity from the external interfaces (or requirements specs) you don't have the same level of strong relationship with the internals that you do with a chip or board or system. So you are unable to reduce variance as much. For this reason, many estimation tools such as COCOMO allow you to add additional data about "expected complexity" of the module to be designed. But these are less precise relationships than the physical constraint relationships of chips and board dimensions. I believe that it is the power of constraint relationships to predict complexity that accounts for why despite everything lines of code has usually the strongest relationship to development time of any typically measured predictor variable. Scott McGregor mcgregor@atherton.com
Chris.Holt@newcastle.ac.uk (Chris Holt) (07/19/90)
In article <27199@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: > > ... In all disciplines management views >their job as making tradeoffs between time, quality and functionality. >This is as true in hardware as software. > ... Engineers don't like to shave >functionality because it is the thing that they want to do--that's why >they entered the trade. Shaving functionality in software *can* mean reducing the available options; it usually means producing something that doesn't always work. It is the non-linearity between the size of the bug, and the size of the resulting error that management seems to find difficult to cope with. ----------------------------------------------------------------------------- Chris.Holt@newcastle.ac.uk Computing Lab, U of Newcastle upon Tyne, UK ----------------------------------------------------------------------------- "Algebraic expression is something that is to be surpassed..."
johnb@srchtec.UUCP (John Baldwin) (07/21/90)
Sure, software can't be estimated with <exact> accuracy, nor can it be measured so. That doesn't make it worthless to pursue software metrics with higher accuracy and precision than we have now. Nothing in life is risk-free; all that management really needs or should want to know is "have we done an adequate analysis of the risks involved, and minimized them to the maximum benefit?" (I'll leave it up to the individual managers and companies to supply their own definitions of "benefit" ;-)) A very good book which, IMHO, builds upon and surpasses the work of the "COCOMO era" is "Programming Productivity" (by T. Capers Jones, McGraw-Hill 1986, ISBN 0-07-032811-0). In it, he gives a synopsis of what he's found through analysis of VOLUMES of data about various software projects, big and small. It is worthwhile reading. In fact, the author did a heavy-duty O/R-style analysis of the data he gathered, and started his own firm (Software Productivity Research, in Cambridge, Mass.) to build and market an estimating tool based on the model he derived. I've seen the demo disk for the PC version; the full-blown estimator sells for $20K... if he can sell enough of those to stay in business, it must be good. (There's a "junior" version available for "only" $5K). -- John T. Baldwin | Disclaimer: search technology, inc. | Some people claim I never existed. Norcross, Georgia | (real .sig under construction johnb@srchtec.uucp | at Starfleet Orbital Navy Yards ;-)
Chris.Holt@newcastle.ac.uk (Chris Holt) (07/22/90)
In article <141@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes: >Sure, software can't be estimated with <exact> accuracy, nor can it be >measured so. That doesn't make it worthless to pursue software metrics >with higher accuracy and precision than we have now. Agreed; except that many people still think if you have digits of precision, that those digits are necessarily meaningful. A garbage number is worse than a very imprecise one *because* it is misleading. ----------------------------------------------------------------------------- Chris.Holt@newcastle.ac.uk Computing Lab, U of Newcastle upon Tyne, UK ----------------------------------------------------------------------------- "Algebraic expression is something that is to be surpassed..."
don@fpssun.fps.com (Don Donaldson xt 2418) (07/24/90)
In article <141@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes: >Sure, software can't be estimated with <exact> accuracy, nor can it be >measured so. That doesn't make it worthless to pursue software metrics >with higher accuracy and precision than we have now... > >A very good book which, IMHO, builds upon and surpasses the work of the >"COCOMO era" is "Programming Productivity" (by T. Capers Jones, McGraw-Hill >1986, ISBN 0-07-032811-0)... I have been reading a very good book on these subjects. It is called "Controlling Software Projects - Management, Measurement, and Estimation" (by Tom DeMarco, Yourdon Press 1982). DeMarco stresses modeling throughout the process. For example, a project plan is a model of the actual project. A requirement specification is a model of the user interface. The software design spec is a model of the software which will be created to fulfill the requirement. In each case, the model should be complete before the actual construction is attempted. And, as in physical construction, metrics can be applied to the model which are roughly proportional to the same metrics as they would apply to the actual product, producing early estimates. On the subject of design, here is a short quote (without permission): "The Did-We-Really-Do-Design Test" 1. Put the design into a sealed envelope. 2. Give the completed software to an outside expert, someone who is not familiar with the original design. 3. Ask your expert to derive the design implied by the implementation. 4. Compare the derived design with the design in the sealed envelope. 5. If the two are not identical, you didn't really do design. don
johnb@srchtec.UUCP (John Baldwin) (07/24/90)
In article <1990Jul21.191009.14229@newcastle.ac.uk> Chris.Holt@newcastle.ac.uk (Chris Holt) [in response to me] writes: > ... many people still think if you have digits of precision, that >those digits are necessarily meaningful. A garbage number is worse than >a very imprecise one *because* it is misleading. Very well-said. --john b.---