kpc00@JUTS.ccc.amdahl.com (kpc) (09/14/90)
What do you think of this as advice to a software ungulate, or to a software engineer? ========== Engineering is a creative act. By that I mean that you have the power to determine the quality of the products that you design. You also have the power to decide what should be designed and what should not be designed. Both are creative undertakings, each in its way. To be an engineer is not to abandon the attributes that distinguish humans from the machines that humans use. To grind out code for the purpose of saying "it is done" is to be a pulp novelist. It is to be an architect of the "functional" buildings that ultimately subvert even their ostensible functions. For every line of code that you write, if you cannot be proud of it, then you are cheapened; if you can be proud of it, then you are elevated. Do not be led to forget this, and do not let management tell you what to be proud of. Expect to maintain pride in what you do and satisfy management's needs at the same time. If you cannot do this, then it is management who has imposed the wrong position on you, for the engineer with unrealistically high standards is mythical. If you discover that engineering is not yours to do, find another field. And when you become a manager, do not let expedience cause you to destroy those qualities that make your best engineers valuable to you and good at what they do. If your wish is to hire a machine, purchase one, or build one instead. When you have the fortune to hire an engineer who is a human being, let him remain a human being. As an engineer, you are a practitioner; to non-technologists, you also represent technology. In these roles, strive to automate those things that should be automated. Strive earnestly to prevent from being automated those things that should not be automated. For every program that you write, consider its efficiency and its usefulness. Consider its safety, its impact on privacy, and its effect on the environment. Consider its beauty and its technical merit. Consider these things and more. Programs, like literature and like architecture, last well beyond their instantiations. In different ways and to different degrees they remain forever as instances of your creativity, of your priorities, and of your decisions. -- If you do not receive a reply from me, please resend your mail; occasionally this site's mail gets delayed. Neither representing any company nor, necessarily, myself.
josef@nixpbe.UUCP (Moellers) (09/17/90)
In <KPC00.90Sep14042337@JUTS.ccc.amdahl.com> kpc00@JUTS.ccc.amdahl.com (kpc) writes: >What do you think of this as advice to a software ungulate, or to a >software engineer? >========== >Engineering is a creative act. By that I mean that you have the power >to determine the quality of the products that you design. You also >have the power to decide what should be designed and what should not >be designed. Both are creative undertakings, each in its way. [Rest deleted, unfortunatly] This is a very idealistic assumption. From my experience in the commercial world, You are told what to design. Usually the quality of the products is dependent on the time frame You have. If Your "customers" (whoever that is) want it NOW, quality has to wait (infinitely). Only a very strong person can withstand this pressure. Even if You say to yourself: "Better late than bad", Your neigbour will deliver junk in time and win the contract. Nobody will ever find out what YOU might have delivered a week later. HE will state that the repairs he'll have to make to the product are "necessary" or whatever. Look at the stuff around and You see what I mean. (Just a couple of thoughts by a disillusioned SW engeneer) -- | Josef Moellers | c/o Nixdorf Computer AG | | USA: mollers.pad@nixdorf.com | Abt. PXD-S14 | | !USA: mollers.pad@nixdorf.de | Heinz-Nixdorf-Ring | | Phone: (+49) 5251 104662 | D-4790 Paderborn |
a1157@mindlink.UUCP (Reece Markowsky) (09/18/90)
>>> Josef Moellers Writes:
< ... >. Only a very strong person can withstand this pressure.
Even if You say to yourself: "Better late than bad", Your neigbour will
deliver junk in time and win the contract. Nobody will ever find out
what YOU might have delivered a week later. HE will state that the
repairs he'll have to make to the product are "necessary" or whatever.
Look at the stuff around and You see what I mean.
I feel this is a very SHORT TERM out look on what is important in the design
of quality software. If the "neighbour" is the type of developer that is
willing to deliver "junk" to gain contracts, in the short run he may very well
win these. However, when the dues are to be paid (maintenance, long-term
reputation etc)... that Junk-Dealer will lose.
(just a few thoughts from a very disillusion future-software engineer)
(/
/) R J Mdavecb@yunexus.YorkU.CA (David Collier-Brown) (09/19/90)
In <KPC00.90Sep14042337@JUTS.ccc.amdahl.com> kpc00@JUTS.ccc.amdahl.com (kpc) writes: | Engineering is a creative act. By that I mean that you have the power | to determine the quality of the products that you design. You also | have the power to decide what should be designed and what should not | be designed. Both are creative undertakings, each in its way. josef@nixpbe.UUCP (Moellers) writes: | This is a very idealistic assumption. From my experience in the | commercial world, You are told what to design. Usually the quality of | the products is dependent on the time frame You have. This may be true, but its a bit off the point. I am often given requirements, which amounts to telling me what to design. I am given time and resource limits, which tell me how much I can afford to do. Yet I still decide what should and should not be designed, what should and should not be done. I can't not decide, unless my job description is changed to ``coder''. On another point, I elect to hold quality constant and vary deliverables. Others do it the other way, and **may** thrive. Yet time wounds all heels: the quick-and-dirty code may not hurt it's author this year, but he'd better change jobs a lot. --dave (if you hold time, staffing levels and size constant, the only variable will be a binary one: success/failure) c-b -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave or just Willowdale, Ontario, | postmaster@{nexus.}yorku.ca CANADA. 416-223-8968 | work phone (416) 736-5257 x 22075
warren@eecs.cs.pdx.edu (Warren Harrison) (09/19/90)
In article <3213@mindlink.UUCP> a1157@mindlink.UUCP (Reece Markowsky) writes: > >Even if You say to yourself: "Better late than bad", Your neigbour will >deliver junk in time and win the contract. Nobody will ever find out >what YOU might have delivered a week later. HE will state that the >repairs he'll have to make to the product are "necessary" or whatever. >Look at the stuff around and You see what I mean. > > I feel this is a very SHORT TERM out look on what is important in the design >of quality software. If the "neighbour" is the type of developer that is >willing to deliver "junk" to gain contracts, in the short run he may very well >win these. However, when the dues are to be paid (maintenance, long-term >reputation etc)... that Junk-Dealer will lose. > I'm not saying this is the right thing to do but keep in mind the junk developer will be around to pay those dues ... the outfit who delivered late to achieve quality will probably be out of business by then becuase they don't win the contract, hit the market window, etc. To have a long- term future, you've gotta' have a short-term future (unless you have an unlimited source of funds :-). As I said, I don't claim this is the way things should be, but on the other hand, I think we could all make more progress if the phrase "as much quality as we can *afford*" wasn't considered taboo among software engineers. Perhaps when people start specifying "quality" (whatever that is) as a part of the contract, the amount that we can *afford* will increase. Warren ========================================================================== Warren Harrison warren@cs.pdx.edu Department of Computer Science 503/725-3108 Portland State University
nancy@murphy.ICS.UCI.EDU (Nancy Leveson) (09/20/90)
I'm not saying this is the right thing to do but keep in mind the
junk developer will be around to pay those dues ... the outfit who
delivered late to achieve quality will probably be out of business
...
But their customers may not be around. Nobody has mentioned that the small
business that buys the junk software often goes out of business or loses
their shirt as a result. I have met many people who have suffered serious
losses including bankruptcy because of junk software. So that the software
developer will make money, they may be knowingly selling a defective product
that they know is likely to harm others.
Yes, I have heard of caveat emptor. We expect this type of argument from
used car salesmen, patent medicine salesmen, and various types of con artists,
but we also do not treat these people as "professionals" and we pass laws to
protect society against them. Is that the way we want society to view us?
I know that it is impossible to provide perfect software. But there is a
difference between putting out the best product we can or one that we feel
meets minimum professional standards and putting out something we know
does not meet those standards.ray@ctbilbo.UUCP (Ray Ward) (09/21/90)
In article <josef.653555416@peun11>, josef@nixpbe.UUCP (Moellers) writes: > In <KPC00.90Sep14042337@JUTS.ccc.amdahl.com> kpc00@JUTS.ccc.amdahl.com (kpc) writes: > >What do you think of this as advice to a software ungulate, or to a > >software engineer? > [...] > >Engineering is a creative act. > [...] > This is a very idealistic assumption. From my experience in the > commercial world, You are told what to design. Usually the quality of > the products is dependent on the time frame You have. If Your > [...] > (Just a couple of thoughts by a disillusioned SW engeneer) This has also been my experience, for the most part, in companies that are organized as a military hierarchy such as "standard" corporations. And technical decisions are made, typically, by technical illiterates. Semi-literates, if you're lucky. IMHO, this comes from two causes. First, the structure of the organization is incompatible with serious intellectual work, which is what most software development is ( at least most systems software -- sometimes I have my doubts about applications software ). The nature of the task would seem to indicate an organization along the lines of a law office, for example. There should be senior partners, partners, clerks, etc., based on the skills, product revenues, client base, etc., of the individual software engineers. This organization has evolved to meet the needs of applying general laws and regulations ( read: standards and accepted practices ) to specific requirements of individual cases ( read: individual software development efforts ). It also handles the needs of developing the younger attorneys through a sort of apprenticeship. In this organization, the intellectual prowess of the individual is respected: cheap lawyers can be very expensive and good -- high-priced -- lawyers can be very profitable. A cheap programmer is about as useful as a cheap lawyer. Which brings me to the second cause. Software engineers are told what to do because software engineers are not respected as professionals. We have not organized as professionals, we have no professional certification requirements or minimum standards, we do not act like professionals ( What self-respecting doctor would meekly accept being told by a patient, "You will perform this surgery using this technique because I'm paying you"? Clear? ). We are treated like servants because we are employees or act like employees even if we are "consultants" -- with some exceptions, of course. We are unable to prevail in controversies over quality because we are economically vulnerable, as well. Again, as part of the organization, we have but a single source of income. Doctors/lawyers have many patients/clients and are financially independent of any single one of them. "Do as I say or I'll cut off all your income," is a potent threat. Granted, there are disadvantages to "certification" and the requirements of "professionalizing" our esoteric art and craft. But I would assert that they are outweighed by the advantages. Indeed, as society becomes increasingly complex and controlled by computers, there will be ever more incidents of software failures; this will cause increasing pressure for regulation and certification. We may in the end have to organize ourselves simply to maintain some control of the regulation, in self- defense. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ray Ward Email: uunet!ctbilbo!ray Voice: (214) 991-8338x226, (800) 331-7032 Fax : (214) 991-8968 =-=-=-=- There _are_ simple answers, just no _easy_ ones. -- R.R. -=-=-=-=
mcgregor@hemlock.Atherton.COM (Scott McGregor) (09/21/90)
In article <9009192047.aa05637@PARIS.ICS.UCI.EDU>, nancy@murphy.ICS.UCI.EDU (Nancy Leveson) writes: > I know that it is impossible to provide perfect software. But there is a > difference between putting out the best product we can or one that we feel > meets minimum professional standards and putting out something we know > does not meet those standards. I think that there is frequently a lot of discussion of this, with apparently polarized views, but when real world cases are discussed there is usually unanamous agreement. Nevertheless, discussion of this topic persists. The point of semantic disagreement is typically what is meant by the "best product we can", since the best one can is typically a function of time and resources. Today's automobiles are much safer than automobiles of sixty five years ago. Given enough time and money, many of today's auto safety technologies could have been built as the very first offerings of car companies that existed then. However this situation is knowledgably absurd since the amount of time for development of some of these technologies would then have been in the decades and investors would not wait that long. Moreover, some improvements would not likely to ever have occurred until a large number of users had experience with automobiles, and engineers learned from on-the-road failures. Of course there have also been considerable improvements from year to year in many other technologies, especially electronics: from CD players and video mini-cameras to powerful workstations with megabyte memories. I believe that the same is true for the software industry. However, the pace of new technological change is somewhat faster for the software industry of today than was originally the case for the auto industry (this also accounts for the concern people have for patent's multi-year lifetimes being applied to concepts in the software area). Additionally, current capital gains laws, and other aspects of the US economy often conspire to reduce the payback period that investors are willing to wait for their money. The net result is that "the best one can" may be much more strongly limited by investment money and time to delivery than to the intellectual capability of the developer. One can fight this, with professional regulation, by forcing out companies who can't get sufficient capital and time to market to meet the stronger professional standards. There would probably be less choice in applications, but those that survived would probably be better. There would probably be less opennings for software engineers as well, but those that did find a position would probably be better paid, be more experienced, and be more highly skilled. The rate of change in the industry would probably decrease too as new introductions were more thorougly tested before being released to the public. However, I believe many software users would not want this situation. I believe the reason is that people continue to KNOWINGLY buy imperfect software. I think the reason why is that in many cases software that does many of the right things much of the time (but does some wrong things some of the time), still makes a substantial contribution; one which in fact people would rather have today than wait for a possibly better solution tomorrow.^1 So early (sometimes poorer quality) initial software often succeeds sufficiently to get enough money to fix it. This situation is also furthered by software developer hubris and creeping featurism. One of the reasons why it may not be important that a product has some strong limitations in some areas is that purchasers may not care about those areas, and may only care about the areas that work. Unfortunately, in many cases companies don't really know the needs of the people who will ultimately buy the product as well as they think they will. So some of the effort in adding extra features (and the testing and quality concerns that go along with those features) are wasted. On the other hand where more attention is needed the customer will often willingly suggest improvements. It is not that they engineers couldn't have thought of them in the first place, merely that they couldn't accurately predict all the improvements that could be done that customers wouldn't ever use. (Most customers only use a small subset of the capabilities that the products provide--even the capabilities on their home VCRs). At the same time, since many customers have a limited understanding of what they need until the use a product, there is an advantage to products that have rich marketing checklists, since many consumers will figure that no matter what they need, at least the richest (most checkboxes) product will be good for them. So there is an advantage to the company who builds a product that is "enough useful" that people will 1) use it, and 2) suggest how to improve it. Ironically, in many cases this is a more successful strategy than building the product that people will use but not suggest enhancements to because it is too rich already. The problem is recognizing the dividing line between the two, and also between useful enough and "not useful enough to pay for". After the sales are in the answers are obvious, but predicting them in advance is an art. Note that this preference for early, even if buggy, products is a reflection of market immaturity. "Early adopters" love new things and are willing to put up with some problems to get them. As markets mature, many more people become concerned with "just the same as the Jones" have, but with as good reliability or sex-appeal or whatever as possible. As some of our markets mature, so may the demands for quality without new features. --Scott McGregor ------ ^1 There are some exceptions to this where people have said that they would rather wait than have a half-working solution. IN MANY OF THESE CASES, SELLERS OF EARLY INADEQUATE PRODUCTS HAVE LOST IN THE MARKETPLACE TO MORE RELIABLE VENDORS WHO SHIPPED LATER. But this is the exception; for most software markets, "he who hesitates is lost").
duncan@dduck.ctt.bellcore.com (Scott Duncan) (09/22/90)
In article <126@ctbilbo.UUCP> ray@ctbilbo.UUCP (Ray Ward) writes: > >IMHO, this comes from two causes. First, the structure of the organization >is incompatible with serious intellectual work, which is what most software >development is ( at least most systems software -- sometimes I have my >doubts about applications software ). Where would you place word processors, spreadsheets, CASE tools, etc.: systems software or applications software? What about libraries of software functions? If you have to be a "programmer" to directly use the product, does that make it systems software? It's just that I've seen some mighty "intellectual" work done in software for applications database design, transaction processing, etc. > The nature of the task would seem >to indicate an organization along the lines of a law office, for example. >There should be senior partners, partners, clerks, etc., based on the >skills, product revenues, client base, etc., of the individual software >engineers. Some of what you say later does not make this distinction and seems to me to lump all people in software into one category. Would you care to say what tasks/job descriptions in typical development would be filled by "senior part- ners" vs "partners" vs "clerks"? Are "clerks" those who code? Do "senior partners" do architecture? Or do "sernior partners" do soup-to-nuts for the hard software projects and "clerks" get the easy projects? > This organization has evolved to meet the needs of applying >general laws and regulations ( read: standards and accepted practices ) >to specific requirements of individual cases ( read: individual >software development efforts ). It also handles the needs of developing >the younger attorneys through a sort of apprenticeship. > >In this organization, the intellectual prowess of the individual is >respected: cheap lawyers can be very expensive and good -- high-priced >-- lawyers can be very profitable. A cheap programmer is about as >useful as a cheap lawyer. I suggest that a law office (like a medical office) is made up of independent professionals who, for business reasons, choose to band together. A lawyer or a doctor can set up individual private practice as well. And they can also choose to associate themselves with a University (teaching) or, in the case of doctors, a large hospital. I think when one tries to apply the analogy to software, it is not clear that each individual programmer would have similar options given the nature of large software systems. But more on that below... > Which brings me to the second cause. >Software engineers are told what to do because software engineers are >not respected as professionals. We have not organized as professionals, >we have no professional certification requirements or minimum standards, Aren't you saying, therefore, that we aren't professionals then? Why expect to be treated like one when your statements make it clear that we do not share many attributes of professionals? The mere use of the word "engineer" in rela- tion to software is a question that has been debated often since most people involved in software do not have engineering certification. >we do not act like professionals ( What self-respecting doctor would >meekly accept being told by a patient, "You will perform this surgery >using this technique because I'm paying you"? Clear? ). We are >treated like servants because we are employees or act like employees >even if we are "consultants" -- with some exceptions, of course. I think this reinforces the point that we deserve what we get, at least by the standards you suggest. I do not argue that what you say about organization and certification is true, but the lack of respect you point out should not be surprising given these things, then. >We are unable to prevail in controversies over quality because we >are economically vulnerable, as well. Again, as part of the organization, >we have but a single source of income. Doctors/lawyers have many >patients/clients and are financially independent of any single one >of them. "Do as I say or I'll cut off all your income," is a potent >threat. If they are their client individually, but if you are a law clerk or internm, you are certainly economically (and otherwise) vulnerable to senior partners and heads of surgery (who really have the clients). Again, if you are a programmer doing the coding for a larger effort rather than the only person on a soup-to-nuts project, you have to expect to have some organizational risks. This is part of the point I mention above about the breakdown of the analogy. I think your points about why we "get no respect" can be valid. The analogy to independent individual professionals does not seem to hold. What about compar- ing us to engineers? Some architects may function independently like a doctor or lawyer, but most engineers have to work for some organization given the size of the projects available. When you get to putting pieces of things together, you no longer have certified professionals doing the actual assembly of the structure, vehicle, whatever. You have union labor whose structure is more like what we see in software from the perspective of craftsman, journeyman, and apprentice. No certification here, just union dues and years of seniority. And these folks are often told what to do. (This is NOT to imply whether such people do or do not perform effectively, etc. I am talking about organization and certification. It is clear nobody suggests that carpenters and bricklayers get university and pro- fessional society certification. They may have trade standards and that may apply as a better model of organization for large software projects despite the intellectual, rather than manufacturing and construction, level of the work. >Granted, there are disadvantages to "certification" and the requirements >of "professionalizing" our esoteric art and craft. But I would assert >that they are outweighed by the advantages. Indeed, as society becomes >increasingly complex and controlled by computers, there will be ever >more incidents of software failures; this will cause increasing pressure >for regulation and certification. One of the negative aspects of regulation and certification is what it does to make the profession more self-serving in some cases. Since you used the legal profession as an example, let me point out that I think there is a great deal involved in the law that exists for the lawyers and judges and not for any clients. It is by no means clear to me that the law has to be so esoteric that we are required (often by other law) to get lawyers to tell us what other law- yers have done because the lawyers (as legislators) have fashioned laws that say you must do so. If you don't get certified, you don't practice, but much of what you describe has to do with an individual client and their attorney (or doctor). Software (custom, commercial variety rather than off-the-shelf) of the size and complex- ity to which you refer is generally built by organizations, not individual practitioners. Tell me what lawyers and doctors band together in such a volume to try a single case or perform one operation? But this is what it will take to build one software system of decent complexity. > We may in the end have to organize >ourselves simply to maintain some control of the regulation, in self- >defense. Possibly true, but I do not think the individual professional example is the one that relates to software. >Ray Ward Email: uunet!ctbilbo!ray >Voice: (214) 991-8338x226, (800) 331-7032 Fax : (214) 991-8968 Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (908-699-3910 (w) 609-737-2945 (h))
gar@spiff.UUCP (Gordon Runkle) (09/22/90)
In article <3213@mindlink.UUCP> a1157@mindlink.UUCP (Reece Markowsky) writes: >>>> Josef Moellers Writes: >>< ... >. Only a very strong person can withstand this pressure. >>Even if You say to yourself: "Better late than bad", Your neigbour will >>deliver junk in time and win the contract. Nobody will ever find out >>what YOU might have delivered a week later. HE will state that the >>repairs he'll have to make to the product are "necessary" or whatever. >>Look at the stuff around and You see what I mean. > I feel this is a very SHORT TERM out look on what is important in the design >of quality software. If the "neighbour" is the type of developer that is >willing to deliver "junk" to gain contracts, in the short run he may very well >win these. However, when the dues are to be paid (maintenance, long-term >reputation etc)... that Junk-Dealer will lose. In the Real World (tm), yes, the Junk-Dealer would get a well-deserved reputation for inferior work, and go out of business. A lot of us, however, do not work in the Real World. We work in the strange and mystical land of Government Contracts. Past performance on other contracts is not a valid consideration in the awarding of new contracts. So the Junk-Dealer can deliver junk to Uncle Sam that is over-deadline, over-budget, and semi-functional. They can milk the government for "follow-on" work or "maintenance", which really means trying (sort of) to get the damn thing to work to spec. Then they turn around and win another contract anyway (as long as they can claim to do it cheaper than the competition). They can keep this up until the government runs out of money. And the government won't run out of money until they've picked every single one of us clean. I've seen this happen too many times to believe that companies here in Sodom-on-the-Potomac (or the government itself, for that matter) really care about doing the job right. -- -=gordon=- -- Gordon A. Runkle, Runkle Research UUCP: uunet!men2a!spiff!gar INTERNET: men2a!spiff!gar@uunet.uu.net, gar%spiff%men2a@uunet.uu.net PH: 703-522-0825 OR 202-566-4382 "UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things." (Doug Gwyn)
EGNILGES@pucc.Princeton.EDU (Ed Nilges) (09/24/90)
In article <27100@bellcore.bellcore.com>, duncan@dduck.ctt.bellcore.com (Scott Duncan) writes: >In article <126@ctbilbo.UUCP> ray@ctbilbo.UUCP (Ray Ward) writes: >> > >>We are unable to prevail in controversies over quality because we >>are economically vulnerable, as well. Again, as part of the organization, >>we have but a single source of income. Doctors/lawyers have many One way of reducing that vulnerability is to do outside consulting on a freelance basis. Unfortunately, this is not possible in many companies: either the workload is so great as to exhaust the software engineer in the performance of his full time job, or there are rules against moonlighting. Also, tax "simplification" (aka "let's screw the unorganized, viz., DP consultants, graduate students, and single parents") has made this somewhat less financially rewarding. But it's still possible when you work for a university. My own employer explicitly recognizes the need to limited outside consulting, both to stay technically current and to supplement a lower salary. > >>Granted, there are disadvantages to "certification" and the requirements >>of "professionalizing" our esoteric art and craft. But I would assert >>that they are outweighed by the advantages. Indeed, as society becomes >>increasingly complex and controlled by computers, there will be ever >>more incidents of software failures; this will cause increasing pressure >>for regulation and certification. One possibility that should frighten us as software people into getting together on this is that of malpractice suits. It's also an informal, on-the-job defense when a manager asks you to bollox up a project in the name of getting it done by a particular date: "I'd love to use a bubble sort in the tight loop of this here patient monitor system, but I personally don't want to get sued when the patient dies while my code is cheerfully swapping records hither and yon." > >One of the negative aspects of regulation and certification is what it does to >make the profession more self-serving in some cases. Since you used the legal Yes, the legal and the medical professions have been self-serving. As a new "profession" we would like to keep our innocence with regards to the sins of these professions, keeping in mind that professions have been described as to some extent "conspiracies against the public." Unions, also, have their sins. But Studs Terkel (no Authority, to be sure: just a Chicago radio guy who's popped off a couple of books) has pointed out that in our society we tend to decry vested interests of all sorts with one rather glaring exception. When corporate managements speak, whether about "productivity" (with or without a negative sign) or a "drug-free workplace" (as if the workplace hasn't been awash in alcohol for 150 years), we jump. "Vested interests" are inevitable in a society based on an adversary legal system. >profession as an example, let me point out that I think there is a great deal >involved in the law that exists for the lawyers and judges and not for any >clients. It is by no means clear to me that the law has to be so esoteric that >we are required (often by other law) to get lawyers to tell us what other law- >yers have done because the lawyers (as legislators) have fashioned laws that >say you must do so. But a good lawyer, like the lawyer portrayed by Danny DeVito in WARS OF THE ROSES, will first do his best to discourage litigation (DeVito tells the story of the Roses in order to discourage a divorce suit). Similarly, a programmer with ethics and integrity will ask his client if, after all, there isn't a package that can do his job for him. If you don't have ethics and integrity, or if you have a secret belief in the nonexistence of true integrity (if you believe that "every man has his price") then best start a trade association, not a profession. And don't expect me to respect you as a professional.
a1157@mindlink.UUCP (Reece Markowsky) (09/26/90)
> asylvain@felix.UUCP writes: > > An unfortunate fact of life is that the company MUST win contracts > if it is survive long enough to attempt including "quality" in it's > products "someday". This means delivering junk now, and winning > follow-on contracts to fix what probably could have been done right > the first time. The piper will be paid, but that'll be the next > guy's problem. (This is one reason Japan out-competes the US in > some areas ... we are beginning to pay the piper for past mistakes) I am disturbed by this. I feel your outlook is somewhat a "manifest destiny", that is, If you truely believe the fact that a sacrifice in quality in your initial products is the key to survival tomorrow you will act this out, even if a project can be completed on time and in good quality. Pressman indicated three important points when it comes to quality: 1. Software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality As I mentioned, with your belief that quality must be sacrificed you will probably not have a complete and accurate set of requirements for the project, let alone conformance to them. 2. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result. "cutting corners" because you think quality MUST be sacrificed, or we won't finish this project is an example of not following criteria - (or if your are following it it's definitely the WRONG criteria). And as you expect, a lack in quality results - but hey! You met your expectations! 3. There is a set of implicit requirements that often goes unmentioned (eg the desire for good maintainability). IF software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect. This third point needs some modification in your case. Here, the "implicit requirments" are the requirements to sacrifice quality to get the product out. And you certainly don't fail to meet these. The outcome however is the same. That is, quality is not only suspect, but is just not there. > asylvain@felix.UUCP writes: > > True, it is short term thinking, but few companies think past > next quarter's bottom line. As a software engineer who wishes > to remain employed, I find I must "go along with the program", and > sneak in whatever quality I feel I can get away with. (It ain't > easy sometimes ... I've put in more than my share of unpaid hours > for a project that should have been scheduled better) > You said it right there! "... for a project that should have been scheduled better". Don't you think that better scheduling, better organization, better planning, could have led to a more successful software project? That improvment on the SQA activities in your organization could replace the idea that quality must be sacrificed now so we can produce "quality" later or as you said "someday". After all, I believe this "someday" will never come for a company with that outlook... the more corners cut, the bigger the tarpit grows!!! -- ------------------------------------------------------------------- Reece J. Markowsky - Computing Science - Simon Fraser University CA. -------------------------------------- - email c371684@csil.cs.sfu.ca --------------------------------------------------------------------- How can you help to make a difference in the software world? "Do all your work with a sense of social responsibility; strive for elegance and beauty; and above all, have fun!" - Grady Booch.
asylvain@felix.UUCP (Alvin E. Sylvain) (09/27/90)
In article <3213@mindlink.UUCP> a1157@mindlink.UUCP (Reece Markowsky) writes: >>>> Josef Moellers Writes: >>< ... >. Only a very strong person can withstand this pressure. > >>Even if You say to yourself: "Better late than bad", Your neigbour will >>deliver junk in time and win the contract. Nobody will ever find out >>what YOU might have delivered a week later. [...] > > I feel this is a very SHORT TERM out look on what is important in the design >of quality software. If the "neighbour" is the type of developer that is >willing to deliver "junk" to gain contracts, in the short run he may very well >win these. However, when the dues are to be paid (maintenance, long-term >reputation etc)... that Junk-Dealer will lose. An unfortunate fact of life is that the company MUST win contracts if it is survive long enough to attempt including "quality" in it's products "someday". This means delivering junk now, and winning follow-on contracts to fix what probably could have been done right the first time. The piper will be paid, but that'll be the next guy's problem. (This is one reason Japan out-competes the US in some areas ... we are beginning to pay the piper for past mistakes) True, it is short term thinking, but few companies think past next quarter's bottom line. As a software engineer who wishes to remain employed, I find I must "go along with the program", and sneak in whatever quality I feel I can get away with. (It ain't easy sometimes ... I've put in more than my share of unpaid hours for a project that should have been scheduled better) Until Quality is mandated from the boys in the glass towers (TRULY mandated, not mere lip-service), us folks in the trenches have to do whatever we can to survive. That probably means more unpaid hours for employees, and working yourself out of a job for consultant/contractors (his code's easy to read ... replace him with a cheaper employee!). <<Questions on job-application: What is your two-year goal? Get employed! What is your five-year goal? STAY employed!! (what do you expect? run for King?) :-) >> -- ------------------------------------------------------------------------ "I got protection for my | Alvin "the Chipmunk" Sylvain affections, so swing your | Natch, nobody'd be *fool* enough to have bootie in my direction!" | *my* opinions, 'ceptin' *me*, of course!
mcgregor@hemlock.Atherton.COM (Scott McGregor) (09/29/90)
In article <3324@mindlink.UUCP>, a1157@mindlink.UUCP (Reece Markowsky) writes: In spirit, I greatly agree with Reece that software quality is a desirable thing, and that steps can be taken to ensure quality. However, the quoted article below offers some opportunity to comment on the relationship between software quality and other important acceptance criteria. > Pressman indicated three important points when it comes to quality: > 1. Software requirements are the foundation from which quality is > measured. Lack of conformance to requirements is lack of quality > > As I mentioned, with your belief that quality must be sacrificed you > will probably not have a complete and accurate set of requirements for the > project, let alone conformance to them. Often it is true that many people do not have a complete and accurate set of requirements for the project, and that as a result quality suffers. Two *implicit* requirements that are often not stated due to their obviousness, is that not only must the software perform according (or close to) specifications, but it must also be completed at an acceptable cost, and within an acceptable amount of time. Additionally, the acceptable tolerance for error is often not well documented. In the real world this is a difficult because it is a nontrivial, expensive, and error-prone task to create complete and accurate specs. This is probably the biggest difference between developing software as part of a pedagogical exercise, vs. developing software for commercial use. In the former, the problem is typically simple enough to be well specified, and objectively testable. E.g. students asked to build a "sort routine" have a very clear spec, and testing for compliance can be easy. In most cases in the commercial environment, the specs that come from marketing or from the customer organization are nowhere near as unambiguous, and so treating them with equal rigor can easily lead to "we did exactly what they asked for, but it wasn't what they needed and so we lost our (contract/job/bonus...). Being a "faultless failure" may feel better than being a "failure at fault", but in the end failing usually has bad reprocussions whether you are at fault or not. Since getting good specs is so difficult and expensive, one must walk a delicate tight rope between spending too much on spec information collection and testing, and not doing enough. Unfortunately, software engineering practices currently provide little concrete recommendations as to what is right and this still remains a poorly understood art. It is complicated by the fact than in many development situations, investors will only spend so much on initial feasibility, or else they will cancel the project before it really gets started. The problem of describing the acceptable "tolerance" for failure also causes problem. Again, in the academic setting, tolerance is often quite easy, typically binary: it met the professor's tests and inspections or it didn't. But with much more complex software, success is typically more than passing acceptance tests and inspections, it is also successful use over a long period of time. A certain amount of tradeoffs between cost and time vs. in field failures is appropriate. The cost of a space shuttle failure is very expensive, and shuttle software is some of the most expensive per line available. Similarly, with medical software. Errors in game software (while annoying) are less fatal, and since low cost and early time to market are more crucial in these markets, people will accept a certain tolerance for failures. Of course, fewer failures are obviously to be preferred, but again steps to ensure this may need to be factored in with the other cost and time requirements. Since predictability of costs and effort is still poor in our field, telling whether the set of requirements are incompatable (not feasible within time and cost limitations) is difficult and often failure-prone, leading to initiation of more ambitious projects than should be attempted. Later when this is recognized, specifications must be modified so that they make a compatable subset, and this will typically include reducing functionality, slipping schedule and budget, and/or increasing tolerance for defects. A final problem in this area is in the case of non-contract software. Here time and cost requirements are even less clearly understood since the only correct values are relative to your competitor's own future time and cost figures and these are even less clearly known. > > 2. Specified standards define a set of development criteria that guide >the manner in which software is engineered. If the criteria are not followed, > lack of quality will almost surely result. > > "cutting corners" because you think quality MUST be sacrificed, or we > won't finish this project is an example of not following criteria - (or if your > are following it it's definitely the WRONG criteria). And as you expect, a lack > in quality results - but hey! You met your expectations! I think that "cutting corners" most commonly comes from following criteria, namely criteria to keep things low cost and quick to deliver. If you are feature or low defect oriented, then you may call these the wrong criteria, but time and costs are important part of the specifications and failure to attend to them is not only equally likely to bring project failure, but also calls into question true dedication to the specifications "whatever they may be". > > 3. There is a set of implicit requirements that often goes unmentioned > (eg the desire for good maintainability). IF software conforms to its explicit > requirements but fails to meet implicit requirements, software quality is > suspect. > > This third point needs some modification in your case. Here, the > "implicit requirments" are the requirements to sacrifice quality to get the > product out. And you certainly don't fail to meet these. The outcome however > is the same. That is, quality is not only suspect, but is just not there. As I mentioned above, this argument under-recognizes other important implicit requirements that go unmentioned, namely, cost and time. Sacrificing cost and time to ensure quality, when budgets and market windows are limited is also self-defeating. Better quality cars CAN be made for upwards of $500,000., but it may be impossible to sell them at that cost. It might also be impossible to get investment capital for twenty years to develop such safety innovations. Cost and time are by no means the only important criteria, but neither are functionality and quality (in terms of low tolerance for defects). Different industries, and even different products will be best suited by differing tradeoffs. It is a clever person who not only manages one or two well, but who can do a good job of satisfying the customer in all three ways. Scott McGregor
albaugh@dms.UUCP (Mike Albaugh) (10/02/90)
From article <31112@athertn.Atherton.COM>, by mcgregor@hemlock.Atherton.COM (Scott McGregor): [... a bunch of stuff with which I mainly agree ...] > The problem of describing the acceptable "tolerance" for failure also > causes problem. [...] > Errors in game software (while annoying) are less fatal, and since low cost > and early time to market are more crucial in these markets, people will > accept a certain tolerance for failures. Of course, fewer failures are > obviously to be preferred, but again steps to ensure this may need to be > factored in with the other cost and time requirements. Is there some sort of Software Engineer's code of ethics that _requires_ games to be singled out as the canonical "who cares" product? I would point out that in 14 years of working on games, I have had (and observed in the work of my peers) about the same bug density as found in the Gnu C compiler, and a significantly _lower_ density than in any of the "shrink wrap" software I have ever used. Perhaps this has to do with the fact that when we have a "real bug" (as opposed to a feature we included that may not meet _some_ customer's expectations) _we_ often eat the cost of sending out ROMS with the fix. We _may_ charge for the ROMS, (i.e. media and handling), but we do _not_ follow the "commercial" practice of charging > 60% of the "new" cost of a software package to fix what were our mistakes to begin with. In other words, "Lighten up dudes" :-) If Lotus/uSoft/etc were to have a similar bug-fix policy, I suspect that a) they would be a bit more careful about testing _before_ they ship :-) and b) they would ship even less frequently and at even higher prices than they do now :-( TANSTAAFL Mike | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!pyramid!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)
mcgregor@hemlock.Atherton.COM (Scott McGregor) (10/02/90)
In article <1161@dms.UUCP>, albaugh@dms.UUCP (Mike Albaugh) writes: > Is there some sort of Software Engineer's code of ethics that > _requires_ games to be singled out as the canonical "who cares" product? I certainly don't mean to claim that "game" software IS buggier, only that the financial repercussions of a missed bug in a game is frequently less than in the case of life and mission critical software. Therefore companies who produce the latter sorts of software MUST demonstrate a certain level of committment in their QA processes. Even with these committments, they may be less effective in finding bugs than a game manufacturer who tries to make the reliability of their games a key differentiator. But the response to shipped bugs may have to be different-- the game company MIGHT offer an alternate game if sales of the original are so low that fixing it is not meritted. A seller of a medical system may not have the alternative of offering a distinctly different kind of system if a patient dies due to a failure in one system--they might face a law suit instead. In any case, features of their markets help determine what will and will not be successful tradeoffs between functionality, quality and timeliness. Game software isoften notably superior to most other software in that it pays lots of attention to quick learning time, low documentation, and other human factors aspect, but it often does so by providing a more limited set of controls and displays. Other software may pay less attention to this area in order to focus the developers on other key aspects for that market, such as rich functionality (aka baroque embellishment), etc. > I would point out that in 14 years of working on games, I have had (and > observed in the work of my peers) about the same bug density as found > in the Gnu C compiler, and a significantly _lower_ density than in > any of the "shrink wrap" software I have ever used. Perhaps this has to > do with the fact that when we have a "real bug" (as opposed to a feature > we included that may not meet _some_ customer's expectations) _we_ often > eat the cost of sending out ROMS with the fix. We _may_ charge for the > ROMS, (i.e. media and handling), but we do _not_ follow the "commercial" > practice of charging > 60% of the "new" cost of a software package to fix > what were our mistakes to begin with. In other words, "Lighten up dudes" :-) This may be a reason, but I think there may be others too. What you are saying is that game consumers judge the product based upon whether they have an enjoyable time, and if the software malfunctions in a certain way (like it bombs just after starting, or lose the score at the end) this may have such serious financial impacts that it is important to set things right by sending new ROMS. Other markets (e.g. freeware or shrinkwrap software) very probably do have other concerns. One of the big differences for many shrinkwrap software products is that many such products are purchased based upon functionality comparison checklists. If your product doesn't have more functions than your competitor, you may lose a lot of business. This causes such software to skew toward more functionality than most games, and sometimes quality is what gives, other times (especially for major vendors like Lotus and Microsoft) schedule may give too. > If Lotus/uSoft/etc were to have a similar bug-fix policy, I > suspect that a) they would be a bit more careful about testing _before_ > they ship :-) and b) they would ship even less frequently and at even > higher prices than they do now :-( TANSTAAFL > If they had such a policy, with such results, they might very well lose their positions in their markets to competitors who were more accurate at meeting that market's specific needs for timeliness, and cost. Scott McGregor
flint@gistdev.gist.com (Flint Pellett) (10/03/90)
It has been my experience that games that are newly minted tend to have a fair number of bugs, but ones that have been through several revisions are usually a lot more reliable than any other application software that has been through a similar number of revisions. They tend to start life buggy because they're developed on relatively low budgets and not always heavily tested. But after they get out into the world for a while, game software has a big advantage over other application software-- it gets pushed to the limit, thereby uncovering the bugs, so that the bugs can be fixed. A lot of other software just isn't used that same way, and the bugs aren't uncovered. For example, in a typical game environment you have a lot of players going full-bore trying to "win" the game, and trying every trick they can think of to do it. The result is that if there is some strange sequence of events that will break your program, or some race condition, somebody is going to try it. (This is expecially true in an interactive game environment, where several players are interacting in the same program at once.) Most game programs also enjoy a large customer base of several thousand (or more) players. Compare this to, for example, software to control a $1M medical scanner, where there may be only 20 scanners just like that in use across the country: you just aren't going to see your customers trying every possible combination of inputs as quickly as they can when some patient's life is on the line, so it may be years before somebody presses button 2 within 1/100th of a second after they pressed button 1 and discovers that some piece of hardware couldn't reset itself that fast. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com