asylvain@felix.UUCP (Alvin E. Sylvain) (10/03/90)
Reece J. Markowsky writes (sorry if I lost the net address stuff): :> asylvain@felix.UUCP [That's me!] 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. I hope you're not advocating that we should adopt "Positive Mental Attitude" (PMA) as a means to providing software quality! "If a man is sure he is going to die tomorrow, he will find a way to make it so." Well, yeah, but PMA ain't gonna save that guy on Death Row. On the contrary, you will find it a rare occasion to have anyone feeling that it is "manifest destiny" to fail to produce quality. Nevertheless, a lot of companies fail to produce quality. I didn't mention it previously, but it should be said ... tight schedules are not necessarily the result of "junk-dealers" trying to win contracts. Yes, there are junk-dealers who under-estimate deliberately, and sometimes maliciously. However, people are just naturally overly-optimistic, and this results in unrealistic goals and unrealistic schedules ... then we're all too busy putting out fires to turn off the gas line (I read that in a posting! I love it!) Excuse me if I shuffle your posting somewhat so my rebuttal will make more sense: :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 :-- : 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. :-- : 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. Hear hear! Dont' forget, tho, we also need individuals who know what they're doing in producing requirements. Too often requirements are produced by: 1) customer, who only knows his business, 2) marketing, who only know what sells, 3) non-technical management, 'nuff said. You also have the problem of top-down management indifference, which permeates the company culture. Read "In Search of Excellence" ... *Every* company talks about quality ... but find one that practices what they preach. : 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. :-- : "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! You are again assuming that I am doomed to failure because I'm assuming I'm doomed to failure, and assuming that I'm assuming that. (did that make sense?) : 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. Too true. And, yes, the "implicit requirements" are to *get the product out the door*. We can argue all month about what *should* be done, and the company has probably defined *all kinds* of development criteria to follow, but the simple fact of the matter is: the boss sez do it *now*. If these requirements are not met, well, I hope your resume is up-to-date. :> asylvain@felix.UUCP [that's still me!] 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? Yeah, you dambetcha! But, as I've said before, this doesn't happen as often as it should, for a variety of reasons. This is kinda like Beatnik/Hippie Philosophy: "If everybody would just *love* everybody, there wouldn't be any more wars!" Too true, too true. But how do you get from point A to point B? :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". Interesting that you should mention SQA, as that *is* the group I was hired into! So, I'll have a chance to work my own ideas about quality, and maybe make a real difference in the world of software. Of course, the real difference has to be made at the front end, and naturally I'm hired into an on-going program. But maybe I can stick around long enough to impact the front end of the next product. Quality can not readily be inspected-in or audited-in. It's better, less expensive and more effective when designed-in from the beginning. The beginning, for your information, is *before* requirements are produced. It needs a top-down commitment from top-management, which us lowly software engineer peon-types have little say in. BTW, before anyone wants to cast aspersions on *my* organization, let it be known that I've only been here for a few weeks. I haven't been here long enough to poison the place with my "negative attitude". :After all, I believe this :"someday" will never come for a company with that outlook... the more corners :cut, the bigger the tarpit grows!!! Hear hear! Does anybody know if any honest-to-goodness top-management types actually read any of this stuff? Otherwise, you're just preachin' to the choir. :------------------------------------------------------------------- :Reece J. Markowsky - Computing Science - Simon Fraser University 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. Lord knows I try! --------------------------------------------------------------------- "Sorry, the reality you have dialed is no longer in service ... please check the number, or pray to your local diety for assistance." -- -=--=--=--"BANDWIDTH?? WE DON'T NEED NO STINKING BANDWIDTH!!"--=--=--=- "If you come in at 10am and leave at 7pm one day, then come in at 6am and leave at 3pm the next day, people will deduce that you are coming in at 10am and leaving at 3pm every day." --- me