a1157@mindlink.UUCP (Reece Markowsky) (09/20/90)
> nancy@murphy.ICS.UCI.EDU 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 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? Tom DeMarco states "I am convinced that most project failures are of this nature (referring to inflated and unreasonable expectations) and are not the fault of the project team at all. It is rather the fault of inflated and unreasonable expectations. The sad consequence of unreasonable expectations is that projects are dubbed failures without any regard for the quality and quantity of work done." It is not just the lack of estimating experience that is the cause of these inflated or unreasonable expectations. With most anything in this world, and unfortuately with estimation in software development, is the influence of politics. Political problems can hamper the extimating process... The politcal problems I speak of are those associated with an "expected right answer". DeMarco puts forward a good example to display this: "Suppose your boss asks you for a set of estimates and, each time you produce one, checks it against a little black notebook that you aren't allowed to see. suppose further that your boss shows evident displeasure at some of your numbers because they don't compare favorable with the numbers in the book. If you're a political animal, you catch on quickly - soon you aren't estimating the work at all, your're just trying to guess what's written in the little black book. Your reward is to be considered a team player. But you didn't build any estimating skills" Now my feeling is that the standards of software development are set too high on average. Companies that have mastered the art of estimation and have developed good estimating models which they continually build on can cope with these standards, 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. Can someone please comment on this. All that I say is from what I read and the little I have seen. Your input would be very much appreciated R J M
a1157@mindlink.UUCP (Reece Markowsky) (09/21/90)
> > Person: Susan Maxwell writes: > > > I've seen this sort of politics at work in my industry experience. An > upper manager > in close contact with the marketplace said "This software will be complete at > this point in time", regardless of the estimates put forth by the > engineers. Quality > per se was not sacrificed, but functionality was cut. This debilitated > the software > to the point that it gained few customers, and the cost of development was > not > recovered. I can't hold the manager completely at fault, however. When > customers > want software that does something, they want it *now*. If you aren't > fortunate enough > to be building that software already, the time crunch is always going to > be there. > > /sfm Can this be attributed to the "gap" that exists between the customer and the developer? This gap encompasses all the misunderstanding and misconception. For example, a customer's misunderstanding of what a prototype actually is could hurt the developer more than it has helped in defining precise specifications! The customer sees what appears to be a working version of the software, and because of the "gap" is unaware that it is held together with (to quote Pressman) "chewing gum and baling wire". They see that prototype and don't understand it when the developer says... well this has to be scrapped.... the product must now be rebuilt. The customer demands that a few fixes to the prototype can be made to build a working product. Pressman says "Too often software development relents". (/ /) R J M
sfm@pepper.NCD.COM (Susan Maxwell) (09/22/90)
|> With most anything in this world, and |> unfortuately with estimation in software development, is the influence of |> politics. Political problems can hamper the extimating process... The |> politcal problems I speak of are those associated with an "expected right |> answer". |> I've seen this sort of politics at work in my industry experience. An upper manager in close contact with the marketplace said "This software will be complete at this point in time", regardless of the estimates put forth by the engineers. Quality per se was not sacrificed, but functionality was cut. This debilitated the software to the point that it gained few customers, and the cost of development was not recovered. I can't hold the manager completely at fault, however. When customers want software that does something, they want it *now*. If you aren't fortunate enough to be building that software already, the time crunch is always going to be there. /sfm Susan Maxwell Network Computing Devices, Inc. Mountain View, CA
davecb@yunexus.YorkU.CA (David Collier-Brown) (09/23/90)
Susan Maxwell writes: | I've seen this sort of politics at work in my industry experience. An upper | manager in close contact with the marketplace said "This software will be | complete at this point in time", regardless of the estimates put forth by the | engineers. Quality per se was not sacrificed, but functionality was cut. A truism in the development industry is that when the customer says "its too big, its too expensive, it doesn't do enough and when is the next release", the developers cheer, hug each other and go out to celebrate. | This debilitated the software to the point that it gained few customers, and | the cost of development was not recovered. I can't hold the manager | completely at fault, however. When customers want software that does | something, they want it *now*. If you aren't fortunate enough to be | building that software already, the time crunch is always going to be there. Well, I'd say the manager blew it: its actually **hard** to deliver such a gutted subset that customers won't accept it. Only a substantial misunderstanding of what the customer **needs** could lead you to that mistake. --dave -- 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
mcgregor@hemlock.Atherton.COM (Scott McGregor) (09/25/90)
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
mcgregor@hemlock.Atherton.COM (Scott McGregor) (09/25/90)
In article <3259@mindlink.UUCP>, a1157@mindlink.UUCP (Reece Markowsky) writes: > > Can this be attributed to the "gap" that exists between the customer > and the developer? This gap encompasses all the misunderstanding and > misconception. For example, a customer's misunderstanding of what a prototype > actually is could hurt the developer more than it has helped in defining > precise specifications! The customer sees what appears to be a working version > of the software, and because of the "gap" is unaware that it is held together > with (to quote Pressman) "chewing gum and baling wire". They see that > prototype and don't understand it when the developer says... well this has to > be scrapped.... the product must now be rebuilt. The customer demands that > a few fixes to the prototype can be made to build a working product. > Pressman says "Too often software development relents". No doubt that the "gap" contributes to software developers not forseeing what customers will want. However, I think that to expect customers to change their WANTS based upon the problems that the developer faces is unreasonable, except in certain captive/contract development situations. In open market situation the customer will typically say "I don't care what your technical problems are. If you can't provide me with XYZZY today, I'll just keep shopping and go to the first competitor that has it. Note that this is not only true for software (where XYZZY might be "Motif look and feel", or "distributed databases"...) but is equally true for everyday products such as cars. Millions of people didn't care what Detroit's engineering and retooling problems were when they wanted smaller more gas efficient cars in the 70's, and so they bought from some other competitors (primarily Japanese and European manufacturers) instead. Even today, people may say they want the safety of Anti-lock brakes, and/or airbags--but at the same price as last year's models. Some companies are able to deliver that and some are not. Those that can use their ingenuity do so to competative advantage--those who can not can only complain that the customer doesn't understand their problems. Of course they are right--but that's little consolation as business is lost and jobs are lost. Scott McGregor Atherton Technology mcgregor@Atherton.COM
johnb@srchtec.UUCP (John Baldwin) (09/27/90)
David Collier-Brown writes: >Susan Maxwell writes: >| This debilitated the software to the point that it gained few customers, and >| the cost of development was not recovered. I can't hold the manager >| completely at fault, however. When customers want software that does >| something, they want it *now*. If you aren't fortunate enough to be >| building that software already, the time crunch is always going to be there. > Well, I'd say the manager blew it: its actually **hard** to deliver > such a gutted subset that customers won't accept it. I would have to agree. In fact, therein lies a good course of action to take when a project *must* be completed on time, and it begins to show uncorrectable signs of going over. Its called "trimming." The smart manager will realize that the original project, as specified and envisioned, will not be complete by the due date. She or he also realizes that if parts of the functionality are NOT "trimmed" by intelligent choice, they will be trimmed by default: whatever gets finished, gets finished. This is likely NOT to be the things the customer needs/perceives-to-need most! The other result of deliberately "trimming" is that what you *do* release can be tested and held to generally high standards of quality. In the case of those who simply choose to "push ahead," testing is one of the things that often gets short-changed. Just my $8.64 worth. -- John T. Baldwin | johnb%srchtec.uucp@mathcs.emory.edu Search Technology, Inc. | "Pereant qui ante nos nostra dixerunt!" | Opinion (uh'pen'yun [noun]): knowledge without the hindrance of silly facts.
rh@smds.UUCP (Richard Harter) (09/28/90)
In article <233@srchtec.UUCP>, johnb@srchtec.UUCP (John Baldwin) writes: > David Collier-Brown writes: > I would have to agree. In fact, therein lies a good course of action > to take when a project *must* be completed on time, and it begins to > show uncorrectable signs of going over. Its called "trimming."... A related concept is design for incremental implentation, which is a very comfortable way to work. *Soapbox mode on* I regularly advocate that software development should be done in the same way the good software maintenance is done. Design and implement an irreducible kernel of functionality to produce a working program. Modify the working program in stages, using incremental refinement and the standard suite of good change control procedures, so that each stage is a working program with defined functionality and testability. Many developers are uncomfortable with the notion of controlled change; however my experience is that development which uses controlled change and which always keeps a working program(s) in hand is a much comfortable and reliable way to work, and that the resulting software is produced more quickly and more reliably. It is not enough to design what a software product should be when it is completed; one should also plan how one is going to produce it. *End soapbox mode* -- 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.
johnb@srchtec.UUCP (John Baldwin) (09/29/90)
In article <199@smds.UUCP> rh@smds.UUCP (Richard Harter) writes: >Many developers are uncomfortable with the notion of controlled >change; however my experience is that development which uses >controlled change and which always keeps a working program(s) >in hand is a much comfortable and reliable way to work, and that >the resulting software is produced more quickly and more reliably. Its a sad but funny fact that, in fact, many developers are more comfortable with the notion of "uncontrolled change." All too many projects (even well-managed ones!) are planned and completed with the view that "once its done, its done." How many of you can remember a real project that was completed and never changed? [I'll admit, there must be a few.] IMHO, the intelligent software engineer (AND his intelligent managers!) will realise that ***the system is GOING to change***, and will begin the project with this a-priori assumption. We might as well manage the alteration process at the beginning. -- John T. Baldwin | "Pereant qui ante nos nostra dixerunt!" Search Technology, Inc. | (A plague on those who said our good johnb%srchtec.uucp@mathcs.emory.edu | things before we did!)
dc@sci.UUCP (D. C. Sessions) (10/01/90)
In article <244@srchtec.UUCP>, johnb@srchtec.UUCP (John Baldwin) writes: > > How many of you can remember a real project that was completed and > never changed? [I'll admit, there must be a few.] > [ Bandwidth conservation at work!] > -- > John T. Baldwin | "Pereant qui ante nos nostra dixerunt!" Yup. In 1980, I wrote a process control system for Westinghouse. Since we had no idea what the guys in the field would want next, we implemented it as an extensible set of functions (yup, functional programming!) bound at application time (using a pseudo-language; the process engineers refused to "write computer programs"). Naturally, after one bug fix and two added-module enhancements, it froze. As of 1985 it had reached revision D (as in, 1.04); in 1989 it was _still_ at rev. D. Moral: the only software which is not subject to major mutation is that which is designed to accomodate it. -- | The above opinions may not be original, but they are mine and mine alone. | | "While it may not be for you to complete the task, | | neither are you free to refrain from it." | +-=-=- (I wish this _was_ original!) D. C. Sessions -=-=-+
dwiggins@atsun.a-t.com (Don Dwiggins) (10/05/90)
In article <244@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes:
IMHO, the intelligent software engineer (AND his intelligent managers!)
will realise that ***the system is GOING to change***, and will
begin the project with this a-priori assumption. We might as well
manage the alteration process at the beginning.
This is one of the things covered by risk management, which is becoming
recognized as an important part of software project management, especially
for large and/or tightly constrained projects (see the IEEE tutorial by
Boehm or the McGraw Hill book by Charette).
--
Don Dwiggins "If you think training is expensive,
Ashton-Tate, Inc. try ignorance"
dwiggins@ashtate.a-t.com -- Derek Bok, Harvard U.