Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!infopiz!athertn!hemlock!mcgregor From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Newsgroups: comp.software-eng Subject: Re: Today's Software Standards (was RE:some advice to a sw eng Message-ID: <30821@athertn.Atherton.COM> Date: 24 Sep 90 18:06:18 GMT References: <3242@mindlink.UUCP> Sender: news@athertn.Atherton.COM Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor) Organization: Atherton Technology -- Sunnyvale, CA Lines: 130 In article <3242@mindlink.UUCP>, a1157@mindlink.UUCP (Reece Markowsky) writes: > > nancy@murphy.ICS.UCI.EDU writes: > > > I am a third year student at Simon Fraser University and do not have a great > amount of experience in the commercial world, but I do have a strong feeling > that these "standards" may be too high. Let me first put in perspective what I > am referring to as standards. There are many standards associated with > software development, and the standards I feel are set too high are those > related to development time. Does the commercial world expect too much in too > little time? Probably yes, many people in the commercial world DO expect too much in too little time. Your and Tom Demarco's comments about political aspects are correct: > The sad consequence of unreasonable expectations is > that projects are dubbed failures without any regard for the quality and > quantity of work done." So why do managers expect too much? I think that the single most important reason, is that the more effective and efficient your development (most customer perceived bang for least buck as soon as possible) the more likely you are to be commercially successful. No one really knows the limits in this area without pushing the envelope, and there is always the fear that competitors will push it more aggressively than you will. So the number one reason for unreasonable expectations is because END CUSTOMERS WANT MAXIMUM VALUE FOR MINIMUM COST, TODAY. The second reason stems from the first, and from aspects of the development problem. This is that quality, value, and time are not LINEARLY tied to development effort. Sometimes one small isolated defect destroys the users ability to develop a habit and undermines the perceived value of an entire system. A small one-day-to-change-and-test modification might make A HUGE difference. Similarly, man years of development can go into building a function that in the end doesn't matter to the customer. Code that was simple to write may be difficult to test, and vice-versa. So much of what has been accomplished in the world has worked according to LINEAR relations that it is the most common intuitive method used in predicting estimates, and yet we see over and over in this field that it gives misleading results. Note that this tendancy follows the entire chain from customer to developer. The customer percieves a "small" amount of functionality value change and so expects the development to be simple. This may also be felt by the manager who brings this to R&D. An engineer might recognize this is not a simple change, but might figure it would only require a small change in R&D or documentation--but each of these groups have to find out for themselves whether this is true or not. It is interesting to note that such non-linear problems (such as fluid flow) were largely ignored in Physics for many years, because they lacked the predictability of the prevailing deterministic and statistical quantum mechanical ideas. Only since the 70s has this area (christened Chaotic Dynamics) been the focus of much attention, and lead to many ideas that challenged the deterministic model that implied that perfect predictability was possible, given sufficient measurement precission. Chaotic Dynamics has lead to the opposite conclusion, namely that due to cyclical interactions and other non-linear relationships, there are phenomenon which are fundamentally unpredictable (e.g. weather beyond 2 weeks), because there is such "sensitive dependence on initial conditions", that even the slightest imprecision in measurement or evaluation of the initial condition is greatly reinforced to the point where the accumulated error quickly swamps the range of prediction. > Companies that have mastered the art of estimation and have > developed good estimating models which they continually build on can cope with > these standards, Note that this implies a substantial barrier to entry to new companies... > but the others (who are poor estimators) are the junk dealers, > or innoncently fail at there software projects and are unfortunately classified > as junk dealers. True. Of course, the unfortunate part is that the pressures from the customers are very real and easy to learn. The ability to predict well often takes much time and support. So, a lot of innocent estimators are at risk while they are learning. The people who work for these companies are also at risk while the company is learning. Unfortunately, our industry is very young and there aren't lots and lots of good estimators out there to hire. So a lot of people's jobs depend on lucky breaks that save them and their company while growing more experienced in estimating. In the meantime, rising customer expectations continue to put pressure on people to test the envelope of their capabilities. This is the driving factor of continual improvements in products and standard of living in a free market economy, This is generally regarded as a societal benefit and this is a reason that certain practices of professional regulation (such as in law, or accounting) have been fought with anti-trust law. No doubt, a certain amount of self-regulation can be good, another amount too much. Finding the optimal middle ground and legally defining that line has always been a troublesome problem--it probably will be so in our industry as well. Scott McGregor Atherton Technology mcgregor@Atherton.COM