Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!msi-s0.msi.umn.edu!srcsip!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!van-bc!rsoft!mindlink!a1157 From: a1157@mindlink.UUCP (Reece Markowsky) Newsgroups: comp.software-eng Subject: Re: some advice to a software engineer (let's get real) Message-ID: <3324@mindlink.UUCP> Date: 26 Sep 90 14:03:07 GMT Organization: MIND LINK! - British Columbia, Canada Lines: 68 > 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.