Path: utzoo!attcan!uunet!snorkelwacker!apple!portal!cup.portal.com!cliffhanger From: cliffhanger@cup.portal.com (Cliff C Heyer) Newsgroups: comp.software-eng Subject: Re: more on estimation Message-ID: <31989@cup.portal.com> Date: 22 Jul 90 16:09:24 GMT References: <812@agcsun.UUCP> <641@dg.dg.com> <831@telesoft.com> Organization: The Portal System (TM) Lines: 208 [The following by cliffhanger@cup.portal.com] Bill writes... >The ability to ship a prototype as a finished product is one of the >curses of our field. Imagine where other engineering disciplines [and society] >would be if it were possible to clone a breadboard or a prototype car at a >cost comparable to that of turning out a production engineered version. >A lot of quality is usually added to a product during production engineering. This is an excellent alternative way to express my point! Thanks Bill. > No contractor >is going to bid on a project unless the design product is demonstrably >well thought out. .... or where he has prior art as a reference. >Nobody has a comparable concern with the internal details >of software. > Software "contractors" are routinely asked to "bid" on projects with NO internal details, and with NO accessible prior art. Then these people are told they are "bad" because they could not make an estimate. I intend to give these contractors some ammunition to fight back with to stop the injustice of this situation. I hope my message reaches some programmers in the situation I have been in - that is being wrong in your estimate with MBA type managers tell you you are not a good programmer. This so angered me that I went to the work to think why this is wrong and thus my postings on the net. When you are educated to the facts, you can say the right things so that the MBA managers can't push you around. What can they say when you explain that programming is NOT like assembly of components in a pre-determined way? They are forced to acknowledge what programming REALLY IS. Without this acknowledgement, they will determine what programming is to support their own interests - And YOU pay the price. (Of course they may be so arrogant that they will laugh at you. If this happens, work on a critical project and then quit just before delivery.) Scott McGregor writes... >> I don't think that hardware engineering works this way. Talking to >> my HW engineering friends I find that they are faced with deadlines >> and schedules just like I am. > >I think that John is correct. In all disciplines management views >their job as making tradeoffs between time, quality and functionality. Note none of these have anything to do with "happiness" of the programmer. >In general, management of software does want solid schedules. Management's focus on this triangle together with often promoting the misnomer that programming IS accurately estimatable causes low programmer morale and fosters programmer obstinacy, all the items Scott attributed to "programmer psychology" below> >I I find >that engineers often internalize their own goals and are less >flexible in changing functionality and quality than management might be. If engineers were treated in accordance with the reality of their work, I think they would be as flexible as any manager could want. I speak from personal experience. I have to fight to force those who hire me to understand what I am speaking of here, because when they do I can be flexible and produce 12-50 lines of tested and debugged code per hour, 10 times the published averages described in IEEE Software and Computer articles. Otherwise I am obstinate and sacrifice my own future along with those I work for and code at 1-2 lines of tested and debugged code per hour. I demand those I work for to respect me, rather than allow them to treat me as a "younger less experienced person who knows less than the manager and therefore should shut up." >I believe that this is a social aspect. I disagree. It is a result of the fact that a company's need to make money has nothing in common with the need of an engineer being happy in his job. I don't propose a solution to this dilemma - it is the effect of the existence and use of money. >Engineers don't like to shave >functionality because it is the thing that they want to do--that's why >they entered the trade. But if they are treated correctly than they won't mind shaving functionality. The engineer attitude you describe results from bad management of "of people" - eg. management of the product without concern that "people" are working for you and being sensitive to their needs. It is very easy to be obstinate when the person you work for shows insensitivity and arrogance. >Engineers don't like to shave quality because >of self-integrity, they want to feel they did a good job by their own >internal measures. The engineers' focus on "internal measures" is CAUSED my management in the first place, not a result of the engineer's psychology. Because management does not provide measures that the engineer can feel satisfaction by (eg. blame them for bad estimation) they are forced to develop their own internal measures so they can feel satisfaction. After this happens, the engineer is no longer responsive to management. >Time frames are typically less important to software >engineers, so they would feel better sliding the schedule and holding the >other aspects constant. This "axiom" is a perfect example of what I am talking about. Let's just say that software engineers are a certain way, and that's the way they are. Never mind how they got that way, for example, because of our own actions as managers. Since I started my own business to "live" the philosophy of my postings in this collection, I've seen my own productivity zoom to an excess of 10 times what I was capable of in the past or in a typical company setting. The "manager attitude" embodied in Scott's posting is what I escaped from. >Since managers often get measured on what ships >and not how much work was done, Yes, the reality of profit being incompatible with employee happiness. This is a sad fact of life, for which I have no solution. I guess I'm proposing the searing crossfire of ideologies be moved up to upper management who get paid more, rather than be subjected to engineers by measuring them by the accuracy of their estimates. >their is a social opposition here. I >believe these are the reasons why we see tension between software >developers and their managers on "unreasonable schedules". Well it all depends on whether you are running a company to make money or running it to make employees happy as possible. If the only goal is only to make money, employees more likely to be treated in a way that will cause them to be obstinate. If you run it for the employees, the company may go broke. I think there is a balance that will net programmer productivity far above where it is now. With a goal of profit companies shoot themselves in the foot. If the goal was for employee happiness, then employees would work harder and in the end the company would make more money than if it forced the issue of profit and created obstinate employees. [Robert I. Eachus's comments deleted but this writer agrees.] Scott McGregor continues... >>[Cliff wrote... ]attempt to create an accurate measure of something that is not >> measurable in the first place. > >Software development time is surely measurable. Yes, you are right. Substitute "accurately measurable" for "measurable" - I forgot a word. >But truthfully everyone who builds tools for predictions >of this sort is usually quite upfront about the fact that they create >predictions of MEANS with some VARIANCE. Well I think I'd be happier to see more management acknowledgement of VARIANCE. Right up to the stockholders. >Clearly, software schedules are predicted by people, and so ipso facto are >predictable, it is merely that the predictions may not be very >accurate. Increased management focus on this will boost programmer moral and thus productivity. > >> Such estimates are bound to be useless because numerous coding difficulty >> assumptions will be wrong without support of actual time measurements. >> These errors propagate in an exponential manner throughout layers of code. >...The [estimates] aren't useless merely because they don't offer certainty >for [program completion]. "Useless" was too much of a work for me to use. Obviously something is better than nothing. Even an estimate 10 times off can still be used to distinguish a 2 month project from a 5 year project, and this is useful. > The alternative, > NO estimate, is often psychological unacceptable to risk averse persons. I don't mean to say it is practical to work with NO estimate. I think that there needs to be MUCH more focus on the fact that the estimate is not accurate, and programmers should NOT receive demerits for a bad estimate when there is no prior art to go by. (prior art meaning development of exactly the same thing, like a car company making a new model car, which is most of the time in software.) [Scott's discussion of HW estimation deleted.] Scott confirmed a key point - that the complexity of hardware component is FIXED, while with software components the complexity is not well understood. (I'm not talking about PLDs, etc.) This ties in with a previous posters' concept of DOMAINS. Software is applied to any domain "on the fly" - it is so flexible. There is no chance to develop components for any one domain, much less share them with other domains. So the software engineer has the work of the hardware engineer PLUS the need to develop all the components at the same time. On top of that, the laying out of circuit boards is pretty much automated. But with software, connecting components requires use of program statements - which must be developed. No wonder there is such an estimation problem! >I believe that it is the power of constraint relationships to predict >complexity that accounts for why despite everything lines of code has >usually the strongest relationship to development time of any typically >measured predictor variable. It's nice to see at least ONE relationship you can count on in software. But unfortunately we can't estimate lines of code any more than development time, so we are no better off! Cliff