[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::digital

Title:	The Digital way of working

Moderator:	QUARK::LIONELON

Created:	Fri Feb 14 1986
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5321
Total number of notes:	139771

1761.0. "Interesting contrast to DEC mgmt style" by STAR::DIPIRRO () Mon Feb 10 1992 11:38

Copied without permission from the 1/19/92 Orlando Sentinel and 
authored by Ronald E.Yates of the Chicago Tribune.

"American managers still insist on managing people instead of the 
system - creating fear and mistrust in the workplace, removing joy..."
                                            - W. Edwards Deming

U.S. management "doomed" to failure

SCOTTSDALE, Ariz. - Jim Glidden had heard the stories and read the 
books. Now here he was with 650 other executives preparing to hear the 
words from the man himself - W. Edwards Deming, the American 
management guru credited with teaching the Japanese how to produce 
top-quality goods.
  Like many at the first day of a recent "Quality, Productivity and 
 Competitive Position: seminar by Deming, Glidden, an industrial 
 engineering and safety manager, had attended a lot of management 
 seminars - many only marginally helpful.
  So Glidden went to Phoenix with his intellectual caution light on.
  By the time he left, after four days of listening to the 91-year-old  
 Deming, Glidden had replaced his skepticism with enthusiasm.
  "I found myself staring at Deming, mesmerized by his message. What I 
 heard him say made a lot of sense. American management is programmed 
 for failure. And that is one reason why American corporations are in 
 decline."
  Actually Deming's message is much more complex than that. It strikes 
 at the heart of the "Management by Objective" and "Management by 
 Results" methods most American companies still practice. And that is 
 one reason many American executives still look a bit askance at the 
 man who is considered a living legend in Japan but remains a prophet 
 without honor in his native America.
  What Deming says at the 20 or so seminars he puts on each year is
 basically what he told the Japanese in 1950. Then, in a series of
 eight-day seminars conducted from one end of Japan to the other, he
 told the shocked Japanese to discard most of what they had learned
 about American management methods.
   The native of Sioux City, Iowa, told the Japanese that emulating
 American corporations would lead to ruin and keep the Japanese from
 attaining the levels of quality and efficiency for which they have
 since become renowned.
   Deming told the Japanese not to make the same mistakes American
 corporations are still making - namely, ranking and annually
 evaluating workers, salesmen, teams and divisions. This only creates
 competition between people and divisions, destroying the overall
 system.
  They should also stop giving merit raises because merit pay forces
 workers to please the boss, thereby destroying morale. They should
 not set numerical goals or quotas for workers or departments because 
 they lead to distortion and faking. They should not erect walls 
 between departments. They should not have inspection teams at the end 
 of the production process. Instead, they should eliminate latent 
 defects at the beginning by understanding and controlling statistical 
 variation. In short, they should manage the system, not the people in 
 it.
  "People want to work, but they want to take joy in their work," 
 Deming said. "American managers still insist on managing people 
 instead of the system - creating fear and mistrust in the workplace, 
 removing joy, rewarding themselves at the top with bonuses and perks, 
 punishing those at the bottom. It is destructive, and it prevents 
 companies from functioning efficiently as a system."
  It was a stunning message for most of the thousands of top Japanese 
 executives who flocked to his seminars. But when Deming backed up his 
 ideas about quality with flow diagrams, formulas and pure old 
 fashioned common sense, the Japanese were convinced.
  So, apparently, were most of those gathered in Scottsdale.
  "I sensed a kind of conversion going on," said John S. Ludwig, 
 director of quality for the Chicago office of the Newark Group, a 
 holding company for 33 companies in the recycled paperboard business. 
 "I walked out of this seminar with a sense of obligation and a 
 feeling of responsibility to influence the leadership of my company."
  "Deming's whole message is that if a company is not doing well, it 
 is management's fault, not the workers' fault," said Robert Baggs 
 Jr., director of training and development for Rudolph/Libbe Inc., a 
 35-year-old Walbridge, Ohio, General contracting company. "The 
 message is cooperation and looking at everything: workers, 
 production, finance, management as part of a system. The message is 
 to optimize the system and then manage it, not people."
  That is a tough pill for many American executives to swallow. And as 
 the seminar was beginning, many of the 40 to 50 chief executive 
 officers attending the $1,000-a-person event were skeptical.
  
  "The kind of management being practiced in American corporations now 
 and being taught at American business schools is the biggest 
 producer of waste, causing huge losses whose magnitude cannot be 
 evaluated or measured," Deming thundered during the second day of the 
 seminar. " Most people in management are not aware that they are 
 imprisoned by current practices of management...that these management 
 practices are the cause of American corporate decline."
  To demonstrate this idea, at each seminar Deming conducts what he 
 calls the "Red Bead Experiment." Ten seminar attendees are picked and 
 assigned jobs. Six are what he calls "willing workers." two are 
 inspectors. One is a chief inspector, and one is a recorder.
  The objective of the Red Bead Experiment is to show how a poorly 
 managed system, not workers, leads to defects and poor quality.
  Deming explains that the"company" has received orders to make white 
 beads. Unfortunately, the raw materials used in production contain a 
 certain number of defects, or "red beads."
  Both the white and red beads are inside a plastic container. The six 
 workers are given a paddle with 50 indentations in it and told to dip 
 it into the container, shake it and pull it out with each indentation 
 filled with a bead. Then they are instructed to take the paddle to 
 the first inspector, who will count the red beads, or
"defects." The second inspector does the same, and then the chief 
 inspector checks their tally, which the recorder then records.

  A worker drawing out a paddle with 15 red beads is put on probation, 
 while a worker with just six red beads gets a merit raise. In the 
 next round, the worker who had six beads now has eight, and the 
 worker with 15 has 10. Deming, playing the role of misguided manager, 
 thinks he understands what's happening.
  
  The worker who got the merit raise is getting sloppy. Meanwhile, the 
 worker on probation has been frightened into performing better. And 
 so it continues - a cycle of reward and punishment in which 
 management fails to understand that defects are built into the 
 system.
 
  "We gave merit raises for what the system did; we put people on 
 probation for what the system did," Deming said. "Management was 
 chasing phantoms, rewarding and punishing good workers, creating 
 mistrust, fear, trying to manage people instead of transforming a 
 flawed system and then managing it."

  Like many executives at the seminar, Glidden understands what Deming 
 was saying, but he also insists that such changes can't come 
 overnight.

  "There has to be a vision...where you want to go," Glidden said.
 "Then you have to get everybody from the top on down on the same 
 train and heading in the same direction."

T.R	Title	User	Personal Name	Date	Lines
1761.1		CVG::THOMPSON	Radical Centralist	`Mon Feb 10 1992 11:55`	12
	Digital used to teach an "Intro to Deming" course. I don't know if we still do. I took it about 7 years ago and it was great. Later I had a chance to take Dr Deming's 4 day seminar. The one written up in .0. It changed the way I think about merit pay and many other "award" programs for ever. One of the points Deming makes though is that his ideas can not work bottom up. This is pretty obvious as he blames 80-90% of quality problems on management. I don't think top management believes in Deming in this company. I don't think they ever will. Alfred
1761.2		VIRTUE::MACDONALD		`Mon Feb 10 1992 12:08`	9
	The Deming philosophy is at the core of the Total Quality Management movement and, therefore, at the core of the the Digital TQM initiatives. The Deming course used to be done by the group which is now known as QEC. If anyone is interested contact the QEC course coordinator, Linda Thomas, at ESMAIL::THOMAS. Steve
1761.3	The future will force the issue.	BASVAX::GREENLAW	I used to be an ASSET, now I'm a Resource	`Mon Feb 10 1992 12:22`	6
	One of the main concepts of the ISO 9000 standard is that Management is responsible for quality. Since Digital is getting licensed under this standard all over the world, I suspect that Deming's message will be hammered into the way we do business eventually. At least I hope so. Lee G.
1761.4		ARTLIB::GOETZE	US 5�	`Mon Feb 10 1992 12:43`	44
	I think the larger issue that looms over this discussion is, 'Are corporations mirrors of our society's thinking process?' and if so, do we need to change some of the cherished beliefs in this system, such as the great god Competition. There seems to be an innate violence in our society which encourages the destruction of whole industries, entire armies of laid-off workers, millions of under-employed (& therefore unfulfilled) workers in the name of laissez-faire capitalism. Anybody see the recent program on PBS entitled "Legacy"? � This only creates competition between people and divisions, destroying � the overall system. An example of how destructive the competitive model is to employee morale is the practice of creating multiple teams or groups to solve the same problem, and not telling each group about the others until after the competition is over. The book "Soul of a New Machine " showed how prevalent this is. U.S. society has ingrained competitiveness that is socialized into its members from childhood. The emphasis on winning at any cost�, the structural features like automobiles which encourage competition, the long (and "glorious") history of dominating other peoples through war�, and the individual isolation of daily life that hides any connection to a greater good or a larger self; these things cannot be changed overnight. They are reflections of the barbaric nature that is in our society's heart. It will take a greater failure than we are experiencing now to jolt the management of American corporations into action. Unfortunately I think that a political solution will be enacted before anything is done voluntarily. The people at the top, for the most part, are too comfortable still. Why is it that we still don't have an "industrial policy"? erik � as exmplified by the exaltation of sports heros into cult heros, gods really, and the Universities allowing flunking football players to graduate, and the pressure on athletes to use steriods. � if only economic and cultural domination. For example, Panama, the Philippines, and Nicaragua.
1761.5	Production only?	PLOUGH::KINZELMAN	Paul Kinzelman	`Mon Feb 10 1992 12:45`	16
	Am I missing something, or do his techniques apply primarily to production? His techniques sound good (as does 6-sigma) to production where you are making oodles of the same thing for consumers. It seems to me to be much less relevant to engineering where we're making the first one of something and moving it to production. Don't get me wrong, clearly engineering must remove bugs and make the widget easier to produce, but too often people apply tools that are blindingly successful in one area, to areas in which those tools do not apply. For instance, 6-sigma and Demming's techniques sound great for applying to a production line. Merely because they are great for production does not mean they fit engineering's task. Other techniques and metrics seem much better to me.
1761.6	Is it applicable to Sales?	SWAM2::KELLER_FR		`Mon Feb 10 1992 13:11`	20
	And I'm not sure how they relate to the Sales function, where personal drive and motivation (something you can only do for yourself) are key to long-term success. Goals here help you to focus on what's most important, such as (for Digital right now) an immediate revenue increase. The problem with most goals systems is not that there were goals, but too often they were imposed from above with no input from below. Digital's movement towards the NMS recognizes the problem with that, and we're moving to solve it. But it takes time, not just for the top to let go, but for the field to pick it up. Both are behaviorial changes that are commonly acknowledged to take time (read "years"). When you don't have the time it takes, and the changes don't come fast enough for whoever is watching, it's too easy for the top to step back in and "solve the problem". Again, while I too think that Deming's principles are just fine for system-controllable processes, I question their application in a Sales environment and would welcome additional discussion around applicability in this particular function. Fred
1761.7	Don't let everyone else obstruct your success	TLE::AMARTIN	Alan H. Martin	`Mon Feb 10 1992 13:28`	28
	Re .1: > One of the points Deming makes though is that his ideas can not > work bottom up. This is pretty obvious as he blames 80-90% of > quality problems on management. ... Yes, he says that. However, I have a germ of an idea that his point need not be important to most of us. From moderate past experience, I suspect that individual contributors and their local management can succeed at deliberately applying modern quality techniques, despite their surrounding environment. I suspect that all it may require is ignorance, apathy and/or slack from upper management in order for motivated individuals to succeed. All management has to do is not obstruct those responsible for production to conduct their own corner of the business in their own way for those using the techniques to succeed. (Sturgeon's Law implies that 9 out of 10 times, the higher reaches of the food chain will be blissfully ignorant that you're managing to do a good job by not letting them mess you up). All the other groups remain free to go to hell in a handbasket, of course, It may indeed be impossible for a corporation to succeed at Deming's quality techniques in a bottom-up fashion, it may be entirely possible for all the readers of this conference and their colleagues to succeed. But given a choice between succeeding while others fail, and failing because others refuse to succeed, I'll take the former if you don't mind. Besides, you never know; management might wake up with a clue one morning. /AHM
1761.8	It's happening here	IW::WARING	Simplicity sells	`Mon Feb 10 1992 13:39`	5
	Re: .6 UK Sales and Marketing are the first pilots in Europe for ISO9000/MQA accreditation in Sales. - Ian W.
1761.9	Tool not equal to concept!	CAPNET::CROWTHER	Maxine 276-8226	`Mon Feb 10 1992 15:04`	8
	re the last few: Quality is a state of mind - not a tool! Whether specific TOOLS apply to your situation or not does not mean that Quality should not be taken seriously. Most of the tools that are in vogue are in fact oriented toward statistical process control. Not true of Voice of the Customer, Contextual Inquiry, Quality Function Deployment, Teaming, Employee Involvement and others. Don't confuse the tool with the concept.
1761.10	Regression to the mean	COUNT0::WELSH	Penetrate the installed base!	`Tue Feb 11 1992 06:07`	33
	All good stuff, and I believe Deming's message is sound. One nit worries me about the Red Bead Experiment, and I am pretty sure I am wrong, because Deming is an expert on the application of statistics. It's the observed fact that the guy who got 15 red beads and was put on probation, improved next time, while the guy who got 8 and had a raise, got worse next time. This is generally thought to imply something about the success of the reward/punishment process. But does it? There was a classic "practical experiment" which should be familiar to all industrial psychologists - I think it took place in the Israeli Air Force. When trainee pilots flew badly, the instructors gave them a fierce chewing-out; when they flew well, they congratulated them. It was observed that the former group tended to fly better on their next flight, while the latter group tended to fly worse. This proves, the instructors reasoned, that punishment works but reward doesn't. There is a simpler explanation: regression to the mean. This simply says that if you do unusually well one time, you are statistically likely to do less well next time. Likewise, if you do unusually badly one time, you are likely to do better next time - on average. The sad fact is that in many such situations, reward and/or punishment have nothing to do with the outcomes. Or at least their effects are swamped. This was a classic case of "managers" believing their actions were more influential than they really were. /Tom
1761.11		VIRTUE::MACDONALD		`Tue Feb 11 1992 08:18`	36
	Re: several Yes, Deming's ideas evolved in a production environment, but they can be and are being successfully applied in other environments as well. Six Sigma, for example, is simply Motorola's Total Quality Management program. They used it successfully in production but also in other areas. Check out the October 25 issue of Business Week which is totally devoted to Quality (my caps because I used the word Quality in the sense that it is being used today i.e. the only thing that matters). Motorola, for example, Six Sigma to their year end closing of the books reducing it from 12 days in 1987 to 4 in 1990 at a savings of 20 million dollars. Check out that issue of Business Week if the issue of Quality interests you. It addresses manufacturing, management, services, R+D, and even the public sector. Programs that have evolved largely from the primary principles espoused by Deming are at work in a number of companies all around us such as Alaska Airlines, Intermountain Health Care (a nonprofit chain of 24 hospitals in Idaho), Ford Motor, Harvard Community Health Plan, The Mac Connection, USAA Insurance, Republic National Bank, Infiniti, Marriott Corp, Four Seasons Hotels Inc., Hitachi Software Engineering Co., IBM, General Electric Aerospace Group, etc. These aren't all just producing widgets. The whole point of what Deming's ideas have evolved to is that satisfying the customer is all that matters and that you'd better have a way of measuring how well you are doing that. Just tracking certs and ships and schedules and costs is not going to amount to a hill of beans if someone else is making the customer happier than we are. If we want to survive, we had better start taking it seriously. Steve
1761.12	I think it applies to engineering	STAR::DIPIRRO		`Tue Feb 11 1992 09:03`	19
	It may be difficult to apply the Deming model to Sales. I hadn't thought about that. However, I definitely think it applies to engineering, particularly in large engineering organizations. At Digital, it's very often been the case where we've had a very short-sighted product vision. If you were proposing a product that would take more than a year and a half to develop...and it would be in an emerging market, forget it...But a year and a half down the road when all our competitors are shipping similar products, the company would be asking why we don't have one and demand we build one yesterday. The point is that engineering very often focuses on short-term deliverables. The management style, reward system, and processes all revolve around this. Schedule, and not quality, reigns supreme. This results in inequities in the reward system, unacceptable quality, and unproductive and unmotivated employees (in many cases). You will be hard-pressed to find engineers at this company that aren't at least a little cynical about the whole development process. Fixing this needs to happen from the top down. Engineers, in most cases, would welcome the change.
1761.13	Quality not applicable to Sales???	WHO301::BOWERS	Dave Bowers @WHO	`Tue Feb 11 1992 09:21`	15
	The only way Quality concepts might be inapplicable to the Sales role is if you have a deep misunderstanding of what Sales is about. Sales isn't about jamming ever larger qunatities of "stuff" down the throats of our customers. Sales is the principal Quality interface beteen DEC and its customers. Responsive, attentive service from the Sales representative and her support team is more important to most customers than minor software bugs. How many customers have we lost due to software bugs? How many (potential and actual) customers have we lost because a phone went unanswered or a call unreturned? -dave
1761.14		REGENT::POWERS		`Tue Feb 11 1992 09:41`	13
	Paul Kinzelman: Just because it takes engineering (or an engineer) six months to two years to develop a product doesn't mean engineering is not a production process. Those six months overlap with another six, and there is a process in place to get from day one to day 180, even if it isn't documented or clearly understood. THAT'S the key to six sigma - know what you're doing and why, and you can learn how well you're doing and how to do better. Tom Welsh: I think this regression behavior is exactly the key to the anecdote in the news article, and without this explanation the article is meaningless on this score. - tom powers]
1761.15	An example of how it could apply to sales.	VIRTUE::MACDONALD		`Tue Feb 11 1992 10:15`	67
	Re: .13 Yes it can apply to sales. Let me construct an example based on the Deliver at Six Sigma class (of which I am a certified instructor). If you're interested read on... Let's say a sales office was concerned about the number of lost sales and want to be able to do something to improve their performance with respect to successfully closing sales. Using the terminology from the Deliver at Six Sigma class we could consider every proposed/expected sale to be a "unit". A lost sale could be a "defect". Opportunities could be anything from the initial sales call, to the written proposal, to phone calls from the customer about the proposal etc. Lets say a sales office started tracking proposals made vs. sales closed on a quarterly basis. Let's say for Q2 they determined that that they made 100 proposals and successfully closed 80 sales leaving 20 "lost". The first step with this data is to calculate TDU (Total Defects per Unit). It is a simple ratio i.e. defects divided by units so we have 20/100 or .20 meaning that .20 of every proposal resulted in a lost sale. Now you factor in opportunities for defects and for discussion let's say that after some analysis of the sales process you determine that there are 50 things in the process of trying to make the sale that could go wrong. Using the formula: TDU * 1,000,000 --------------- = DPMO (defects per million oppty) opportunities You would end up with 4000 or for every 1,000,000 opportunities for either successfully advancing or losing a sale that you encountered during some sales process, you'd have 4000 cases where the result of that opportunity produced a lost sale. That would translate by the way into about 4.1 Sigma. So now you have it reduced to some number. Are you through? NO! You start looking at the 20 lost sales i.e. your defects and collectively your sales team analyzes what happened. You might track the proposal through the process looking for how the sales team handled each step of the process looking for evidence that will help you understand why you lost the sale. When you find things that you think contributed to that, you look for ways to improve the process of making sales so as to reduce the future rate of lost sales. How will you know if you are being effective? Wel, what is the continued tracking of lost sales data telling you? Has your sigma rate gone up after you've made some changes to the sales process? If so then you're on the right track keep plugging. Has it gone down or not changed? Then you're pursuing the wrong path for improving this problem, you need to look elsewhere. What do you do once you've successfully started to improve the rate of lost sales? Perhaps you start to measure whether existing customers are satisfied with the way you manage their account and after that you could..... Steve
1761.16		WHODA5::DECOLA		`Tue Feb 11 1992 10:45`	11
	re: .-1 As long as you remember that an economic downturn should not affect your defect rate in a manufacturing plant, but certainly will in the sales example. And in manufacturing you have more control of the process than you have of the economy. I'm not saying that Sales can not use a Six Sigma type analysis, only that its a bit more complicated and easy to draw the wrong conclusions. -John-
1761.17	It ain't the 'economy'. It's YOU!!	CGOOA::DTHOMPSON	Don, of Don's ACT	`Tue Feb 11 1992 11:10`	49
	re: .16 Bluntly: No, it won't. IF you are selling a product which has a value, IF your product is, for some reason, better than the competitors' IF your product provides a benefit to business, then... A bad ecomonmy is good for you. In fact, in OUR business, if we actually knew what we were doing and did it right, we should thrive. In bad times because businesses need proven automation to cut costs and become more efficient. In good times because businesses can experiment with technology and prove or disprove their theories. We should only suffer - and then just slightly - when things are neither rising nor falling. As to Quality in sales -> assessing an opportunity is a sales process which certainly could benefit from the introduction of some form of Quality control. One of Digital's big downfalls, is the 'management standard sequence' of events which can be paraphrased as: Big Boss: Charlie, you're in charge of X. Do it well. [9 months passes] Big Boss: Charlie, we're really disappointed in X. Your numbers are pretty bad and contributing strongly to our loss this year. Charlie: Yes, boss, but... I've been putting all my efforts into Y, which as you know addresses a quadrillion dollar totally untapped market and next year I can contribute three zillion dollars profit if we can just get Ralph to shift the marketing focus a bit. Big Boss: Charlie, I don't know if you're the right... Charlie: Think of it, Big Boss, THREE ZILLION DOLLARS!!! You could be famous!! People will worship your foresight. and so on. No responsibility, No Accountability, probably no ability. But as long as we have the "Wait'll next year!" coaches, we won't get any pennants.
1761.18		SQM::MACDONALD		`Tue Feb 11 1992 11:39`	14
	Re: .16 Yes, but in the event of an economic downturn that provides all the more reason why you want to know what contributes to lost sales. If you understand the sales process and what parts of that process contain elements which can lead to lost sales, then you have a big leg up on your competition for the fewer customer dollars that are out there. Remember we are not talking about measuring this so that we can find whom to fire or demote, but so that we can improve the process so that we generate more revenue. Steve
1761.19		ESMAIL::CANELLA	give me everything	`Tue Feb 11 1992 11:54`	23
	> In fact, in OUR business, if we actually knew what we were doing and > did it right, we should thrive. In bad times because businesses need > proven automation to cut costs and become more efficient. In good times > because businesses can experiment with technology and prove or disprove > their theories. As an economist, I just don't know how you can argue this point. First off, a recession is usually associated with a reduction in capital spending. In the specific case of the high tech industry, the recession started a lot earlier than it did for other industries because customers reduced their capital spending sooner. In bad times, businesses don't usually act very rationally and, instead, run around looking for short term balms, like layoffs. This is as much a financial issue as it is an organizational issue, viz. some companies tend to behave as "contrarians", that is going against the normal views held at the time. Up until recently, DEC was contrarian, preferring to invest during slow times and not layoff anyone. As the recent news items show, that is now history. DEC is now just another mature company with a terrible stock price but, if I may add, with a very good product line. It will only come out of the doldrums when the economy starts to heat up again. Alf
1761.20	It's not OUR fault. ---- did it!	CGOOA::DTHOMPSON	Don, of Don's ACT	`Tue Feb 11 1992 13:23`	31
	Re: .19 and how I can argue the point... I can argue the point because I am not locked into an endless analytic paradigm. For example: "If capital spending is down, then maybe we should LEASE!!!" The high-tech industry entered the recession first because the high-tech industry deserved to do so. More than others, we were dominated by people whose success was a result of circumstance rather than work. Bill Gates, as an extreme and unbelievably text-book example. It is a poor workman who blames his tools and a poorer CEO who blames the times. Those businesses who react irrationally in whatever times should change management or die. Those who look for short term solutions WILL die. Yes, it may take some time but they WILL die. If you want examples of successful high-tech type things match the growth of NCR with the appropriate economic indicators (whatever they may be) from 1850-1925, IBM from 1930-1975. There are others. Once you've found them, look not to numerical analysis for why some survive and some die - it WILL NOT BE FOUND THERE! Look to the nature of the organization as a reflection of the PERSON in charge. There are many clich�s around the concept "When the going gets tough, the tough get going." and most have some basis in truth. Simply put, our own personal recession is the result of MBTWWGWTWE. (Management by those who were great when things were easy) And, it will continue REGARDLESS of external circumstances until the problem is addressed or we (Digital) go away.
1761.21	Don't forget the other number in the ratio	REGENT::BROOMHEAD	Don't panic -- yet.	`Tue Feb 11 1992 14:32`	9
	John in .16, Although an economic downturn will affect your total sales, it should not affect your defect rate. Remember that that rate is a ratio of lost sales to sales opportunities. Bad times means fewer sales opportunities. What happens to the loss:total ratio in bad times is still a quality function. Ann B.
1761.22		SQM::MACDONALD		`Tue Feb 11 1992 14:41`	13
	Re: .21 Ann, You are right that in bad times it is still a quality function, but bad times could affect your defect rate. You might find some additional number of customers who choose not to buy simply because of the economic uncertainty preferring to conserve their cash, BUT if because of doing causal analysis you know that is the reason for the increase in defect rate, you can implement appropriate responses to that fact and not cast about in the dark hoping to reverse it. Steve
1761.23	Formal inspection is a cruel joke at DEC	WLDBIL::KILGORE	DCU Elections -- Vote for a change...	`Tue Feb 11 1992 15:32`	44
	I don't know anything about Six Sigma. My only exposure to such programs is the formal inspection process, and I think I know enough about it, and about Deming, to state that it is a painful, expensive flop in software engineering. With formal inspection, we have paid lip service to Deming's philosophy while having a net negative effect on our software development process. This is because we should be using formal inspection as part of a comprehensive effort to instrument, feedback and modify the process of software development in a continuous, closed cycle that will eventually allow us to produce software as quickly as possible with zero defects; but instead we accept the first part of the loop, marvel at all the defects we prevented from leaking to the customer, and continue to use it as an inefficient filter for a flawed process. Formal inspection of software is dreadfully difficult and expensive. By itself, it adds to the length of the software development cycle, and eliminates very few defects that a good (and reusable) test system would not also uncover. The only possible justification for this dreadful expense is that it can be used as instrumentation for the process, to provide feedback to previous stages, so we can make educated changes at those stages and monitor the results. And there's the problem. For going on seven years I have participated at verious times in the gathering of raw data for this instrumentation, in the vain hope that I would see someone gather it all up, make sense out of it and at least propose changes to the software development process, even if the changes were just to suggest training or define prerequisites. To my knowledge, and with the rare exception of a local person looking at one or two cycles and making observations that never really led to anything, the feedback and process correction parts of this closed cycle have never happened. As a method of statistical process control for the software development process at DEC, formal inspection is a cruel joke. Now "Inspection" is a holy word. Inspecting your documents, Inspecting your code, this is all great goodness. Managers treat you with disdain if you don't Inspect. People believe you're not a forward thinker if you hold that the time you throw away on one-shot inspections, if they're not followed by feedback and educated process corrections, would be more profitably spent on comprehensive testing. But all my experience shows this to be true.
1761.24		CHRCHL::GERMAIN	Improvise! Adapt! Overcome!	`Tue Feb 11 1992 16:16`	9
	I think it's a little more complicated than the ratio of wins to opportunities remains the same... For example, a customer may have (in good times) bought from the high priced house, because they wanted the best. During tough times, they may buy from the cheaper house because they figure they can live with it. Gregg
1761.25		SQM::MACDONALD		`Tue Feb 11 1992 16:22`	43
	Re: .23 >Formal inspection of software is dreadfully difficult and expensive. In my experience instructing Six Sigma for Software, there have been a number of classes where individuals with experience in Formal Inspections have disagreed with this. The process is disciplined, for sure, and intensive i.e. if you do it right a two-hour at a time session will be all you can handle. Up front it takes a bit of training and effort to become proficient (and what doesn't?), but that all washes out as a group gets more used to using it. >By itself, it adds to the length of the software development >cycle, and eliminates very few defects that a good (and reusable) test >system would not also uncover. Initially it adds to the development cycle, but where a group is patient enough to stick with it, they get all of that time and more back during the test cycle, because the test cycle has fewer problems to find. As a technique for detecting defects, it is slightly more effective than the traditional field testing process, but where you make the very big gains is with cost. Every defect found earlier in the process by the formal inspection method significantly reduces the cost and time you'll have to invest in testing and maintenance. >The only possible justification for this dreadful expense is that it >can be used as instrumentation for the process, to provide feedback >to previous stages, so we can make educated changes at those stages >and monitor the results. And if we were to do just that, we would significantly reduce the cost of maintaining a product through the software life cycle. I don't doubt that your experience has been as you describe, but there is other experience in Digital which directly refutes yours. I can refer you to groups in Digital with proof of that. Send me mail offline if you are interested. Steve
1761.26		FIGS::BANKS	Vice President in charge of VMSMail	`Tue Feb 11 1992 16:24`	24
	Picking just one part of a quality process as described in .23: Doing inspections without using it as a feedback mechanism into the process, is the best way I know to break an otherwise good strategy. Unfortunately, it happens all the time. Someone will decide to "implement a comprehensive new quality program" in their department. They see "inspections". That's good, because it tells the engineers what they got wrong. Then, they see the part about using that as feedback to modify the process. WAIT A MINUTE! Modify the process? Why, there's nothing wrong with the process! (Read: Wait a minute! Modify the process? That's MY turf! NFW!) Until EVERYONE can accept that quality is their job, and that this means hearing things that they might not want to hear, then nothing's going to get better. Things that people might not want to hear are: You need more education The process needs adjustment This is going to cost money to fix EVERYONE has to be willing to accept this feedback, including those who implement those "bold, comprehensive new quality programs". Otherwise, we end up with what .23 describes.
1761.27	Six-sigma may be the wrong road...	CALS::THACKERAY		`Tue Feb 11 1992 18:44`	23
	I am very suspicious of the attitude that seems to prevail, viz: formal inspections as a part of six-sigma, particularly to do with software. Unfortunately, the "marketability" of a product is not necessarily to do with the fewest number of bugs. Rather, it is to do with whether the software solves a problem. I have known many programs, for example, which have few or no bugs. But they are unsaleable. Perhaps we can all come up with examples from our own portfolio. QFD (Quality Function Deployment) is a method which simultaneously designs the product development process, as well as the product itself. And the best process is one in which the "inspection" and "statistical analysis" procedures are completely designed out. Frankly, I am dubious about the entire six-sigma approach. It is tending towards an anti-Deming system. I am sure that W. Edwards Deming never promoted the old Taylorism of "Make, Inspect, Reject, Rework, inspect, reject, rework........" But that's where I see six-sigma going. Sincerely, Ray
1761.28	If you like "process", try cheese!	CGOOA::DTHOMPSON	Don, of Don's ACT	`Tue Feb 11 1992 19:09`	24
	Six-Sigma, like just about any other methodology is but a map for the navigator who has no idea where he's going in the first place. Perfection may be a noble but is a pointless pursuit. Goods & services are produced by people. People make mistakes. IF the people are enthused about what they are doing and properly LED, they will want to rectify those mistakes. And they will. If they are relegated to the role of 'human resource' the natural desire to do a good job will be dulled out of them and the product/service will suffer. No amount of 'procedure' and 'process management' in the world will result in better response on, for example, a Customer Support Line, than a committed and well led human being. No formal feedback loop is likely better than the willingness of and opportunity for an employee to butt in with an observation on what's happening. Atmosphere and attitude is vitally important. Don
1761.30		SQM::MACDONALD		`Wed Feb 12 1992 08:27`	49
	Re: .27 >Unfortunately, the "marketability" of a product is not necessarily to >do with the fewest number of bugs. Rather, it is to do with whether the >software solves a problem. It seems that perhaps formal inspections are perceived as just a way to eliminate bugs. Not so. They are a method for checking your work along the way to ensure that the process is, indeed, producing what you intend it to. Code is not the only thing that gets inspected. Any other documents, specs, requirement, etc. are inspected as well. >QFD (Quality Function Deployment) is a method which simultaneously >designs the product development process, as well as the product itself. Six Sigma strongly encourages the use of QFD. >And the best process is one in which the "inspection" and "statistical >analysis" procedures are completely designed out. This I have to disagree with. There may be specific inspection and analysis procedures or methods that outlive their usefulness, but the need to inspect i.e. be sure that you are continuing on the right track and constantly improve the process never goes away. >Frankly, I am dubious about the entire six-sigma approach. It is >tending towards an anti-Deming system. I am sure that W. Edwards Deming >never promoted the old Taylorism of "Make, Inspect, Reject, Rework, >inspect, reject, rework........" But that's where I see six-sigma going. Inspection in the sense of formal inspections is not in the same sense as has been proved by Deming to be the wrong thing to do. That sense is that you "inspect" samples of what the process is producing so that you can fix them before shipping them. That is not what formal inspections are about. Their intention is to inspect for evidence that the process is going astray so that we can fix the process. Bugs or problems found during the inspection are just the evidence of that. It is becoming clear to me that there are many different perceptions going around about Six Sigma, QFD, Formal Inspections, TQM, etc. that may be based on hearsay or simply perception and not actual/factual introduction to the methodology and what it is all about (So what else is new). Please do yourselves and Digital a favor. Before you decide that it doesn't or won't work, find out the facts first. Steve
1761.31		WLDBIL::KILGORE	DCU Elections -- Vote for a change...	`Wed Feb 12 1992 08:47`	24
	re .25: I would be interested in talking to any group that has actually used formal inspection to instrument a software delivery process, provide feedback, change the process and measure the results. I'll bet a hamburger that no software group in DEC has closed the loop. No one can argue with you that it's better to find a problem early than late. But I contend that unless all its instrumentation overhead is used to actually feed back into the process and recommend changes, formal inspection is the worst method to detect software problems, at any stage. >>The only possible justification for this dreadful expense is that it >>can be used as instrumentation for the process, to provide feedback >>to previous stages, so we can make educated changes at those stages >>and monitor the results. >And if we were to do just that, we would significantly reduce the >cost of maintaining a product through the software life cycle. My point, precisely, is that we don't.
1761.32	Confused or confusing?	VAULT::CRAMER		`Wed Feb 12 1992 08:55`	29
	I have been involved with application software development for 12 years. During that time I have seen many different processes or methods used which held out assurance that "if you do this all will be well with the world". I can't tell you if that assurance was justified in any of the cases. Why? Not once was the process or methodology followed through to completion. There was always some excuse, usually "we don't have the time", for skipping some steps. All I have heard of 6 sigma, TQM, QFD and the like lead me to believe that we won't be any more successful with those processes than we were/are with the ones tried in the past. The simple fact seems to be that all of these are aimed, correctly I might add, at long term success and improvement. In the world of application development in DEC long term is 6 months. Which is also about the length of time you can count on keeping a team (management included) together. And BTW, don't try and review a completed project to see what went right or wrong; you don't have the time and you don't want to embarrass anyone. So here are two questions for all you quality experts out there: 1) How can you evolve a process of "constant improvement" in an environment with no consistency of organization, personnel or purpose? 2) How can you implement an honest appraisal of defects in a process which is primarily or solely comprised of individual brain power and emotion when society (and DEC in particular ) excoriates the notion of individual responsibility for one's actions? EG in Sales or Software Development Alan
1761.33		SQM::MACDONALD		`Wed Feb 12 1992 08:57`	39
	Re: .28 >Six-Sigma, like just about any other methodology is but a map for the >navigator who has no idea where he's going in the first place. Is your point that just knowing where you want go is enough? > Perfection may be a noble but is a pointless pursuit. Tell that to our competitors. >Goods & services are produced by people. People make mistakes. IF the >people are enthused about what they are doing and properly LED, they >will want to rectify those mistakes. And they will. If they are >relegated to the role of 'human resource' the natural desire to do a >good job will be dulled out of them and the product/service will >suffer. I agree with you totally, but I am bothered by something that I think is implicit in what you are saying. It seems that you are saying that their natural enthusiasm and interest in doing well by itself will be enough for them to succeed. That is precisely what Deming is saying is wrong. For sure what you say is true, but Deming's point is that if you insist on giving them a methods and processes, which can't possibly produce the result that you want that then their desire to do well will be "dulled out of them" as you put it. Think of it this way. Deming is saying that if you hire a person to be a carpenter and provide a rock to drive nails with while your competition is providing a hammer, then you are wasting your time encouraging your workers to be enthusiastic and do better to beat the competition. With the wrong tool, they were out of the game before they were in it. Try some of Deming's writings. He says it better than I do. Steve
1761.34		SQM::MACDONALD		`Wed Feb 12 1992 09:05`	8
	Re: .31 As I said, contact me offline if you want a pointer to who is doing this. Steve
1761.35		SQM::MACDONALD		`Wed Feb 12 1992 09:10`	22
	Re: .32 > 1) How can you evolve a process of "constant improvement" in > an environment with no consistency of organization, personnel > or purpose? You can't. One of the fundamental principles of TQM, Six Sigma, etc. is that you must move your company in the direction of doing this, that is, if you want to stay in business. > 2) How can you implement an honest appraisal of defects in a > process which is primarily or solely comprised of individual > brain power and emotion when society (and DEC in particular ) > excoriates the notion of individual responsibility for one's > actions? EG in Sales or Software Development Again, you can't. In this case the process you describe itself is a defect. That is one of the things we must fix. Steve
1761.36	The we have the cart before the horse	VAULT::CRAMER		`Wed Feb 12 1992 09:24`	20
	re: .35 Then we should not be bothering with six sigma, TQM etc. until we fix the more basic problems in DEC. All these quality assurance methods are doomed to failure and will get an undeserved bad reputation until the management pattern is changed. Until we can develop a stable organization with measurements that are directly related to the stated goals of the company all the quality programs in the world will do nothing more than feed our delusions. Alan PS Someone in here mentioned that Deming does not believe in merit pay. How, then, does he avoid the well known problem of labor sinking to the lowest common denominator. The "heck, Joe is goofing off and gets the same pay I do; why should I work hard?" syndrome. It is a known, demonstrable fact that letting slack workers get by is bad for morale and productivity of workers that had been doing good work.
1761.37		FIGS::BANKS	Vice President in charge of VMSMail	`Wed Feb 12 1992 09:59`	12
	I don't know what all this Demming vs Six Sigma debate is about. Isn't it possible that they're both right? Isn't it possible that either approach would succeed? Yes, it seems clear that a halfhearted attempt at either of them will fail, and it seems equally clear that an attempt to implement both at the same time would fail as well. It also seems clear that there can be more than one solution to a problem. It seems pointless to argue about which is "better" or more "right". It seems a lot more relevant to discuss why it hasn't been possible to implement either within our respective organizations.
1761.38		CALS::THACKERAY		`Wed Feb 12 1992 10:27`	25
	Re .30: > Before you decide that it doesn't or won't work, find out the facts first. Just because you and I don't agree does not mean that I do not have the facts, so this rather arrogant comment does not cut ice with me. In point of fact, I have gone to significant lengths to find out about six-sigma, and have drawn some conclusions, not all of them nice. I am indeed negative about some of its aspects, the most important of which is the EMPHASIS, placed by practicioners, on the back-end of the product development process. In general, we need less of the "formal inspection" and statistical analysis, and more of the up-front product and process development. Yes, I know that QFD is touted in the overall six-sigma approach. But so is everything else. But the plain fact of life here is that QFD is only implemented as a Requirements Analysis methodology, and taken no further. This fact alone dooms six-sigma to ultimate failure. But the emphasis placed in training and documentation for six-sigma, and the perception by the people who are attempting to implement it, particularly for software projects, alarms me. Ray
1761.39	Belly-button lint	CGOOA::DTHOMPSON	Don, of Don's ACT	`Wed Feb 12 1992 10:31`	26
	re: .33 My point on navigation is: While just knowing where you want to go is insufficient on its own, without knowing where you want to go, all the help in the world won't get you there. (Except of course by random chance.) As to perfection, it is unattainable. If the goal is lowered to 'our best', people can be motivated to go for it. As the software development discussions have correctly pointed out, there is more to perfection than simply no bugs. In general, as has been mentioned, Digital's management's culture is not conducive to serious feedback. Navel gazing is permitted, but no-one may comment on another's anatomy, save to tell the boss his is really cute and nod at all other observations. Perhaps the advantage Digital might glean from any of these processes lies in the opportunity to say: "Here's a new way..." without actually mentioning that the 'old way' has failed us. Of course, any implementations should start in YOUR area, as mine is just fine, thank you. Don
1761.40	Quality costs, but who'll pay?	FRITOS::TALCOTT		`Wed Feb 12 1992 10:57`	68
	I've seen a bunch of Quality programs come and go in the groups I've worked in at ZKO in the last 10 years, including QA Buddies, Formal Inspections, some Six Sigma, etc. There was even a time when we were told that a specific section on quality was going to be part of our reviews (never happened that I'm aware of). I moderated perhaps 20 or so Formal Inspections, including some that started at functional specs and took it all the way through to the code. For the most part, the people whose work was inspected were pleased with the efforts, which makes sense as those who didn't believe in it wouldn't participate. It certainly is expensive - we have someone on our project who can (and has) written 2000 lines of code in a weekend. My (admittedly old) Inspector's Handbook recommends inspecting Non-commented Source Statements at 125 lines/hour. That's 8 (16 hours / 2 hours per insp) inspections. The Handbook says total time for an inspection will vary from 13 to 21 person hours. Depends in part on how many people are involved. Say it's 18. That's 144 person-hours for one weekend's work by one person. When was the last time you did a 1-year schedule and added, oh, another year in there for formal inspections? It just doesn't go over that well with the management types. It's also recommended that you bring in people outside your project who are either very knowledgable in the field of the material being inspect or "experts". We had a few very technically astute people who were much in demand - so much so that they had to be "rationed" - you don't want your consulting engineers spending all their time in inspections - and they won't want to spend their lives there, either. On the other hand, the Handbook gave some comparisons of what it cost to fix a problem in the early stages design to coding, versus a bug in a released product and what it costs the company to handle/close an SPR. The savings, way back in 1982, was calculated for a small sample at over $4500 per problem for every fix that precluded an SPR. It's been a decade since I took the Formal Inspection Moderator's course, but I believe I recall being told that someone - IBM? More likely Tandy? had done 100% formal inspections on a version of their operating system and had received something like 2 bug reports on it in a year. Wouldn't it be nice to ship, say, VMS V5.5, and have perhaps half a dozen bug reports? Attainable? Probably not, but imagine the resources we could free up and the happy customers we'd have if we could do it. If we had reusable software packages that could be inspected once and re-used by many it would certainly help the cost ratio. I haven't seen many great strides toward that goal (in the U.S. - hint hint), although the DECwindows widgets are a good start. It pains me to think off all the time many of the software products I know spent when we first went coding the DECwindows interfaces. There were at least some bright spots - Notes and CMS shared bunches of low level code, then CMS did the same thing with DTM. In fact, several of the CMS people assisted the DTM team in doing the first version of their DW code. Was the code formally inspected? No. Did we continue to share a single set of sources? No. But at least when one group found a bug the others could be notified. The other great side effect of not sharing the code was tons of dissimilarities in user interfaces for products whose developers sit within 150 feet of each other. Remember the old flip-chart that was produced for things like Debug and the VAXset tools that had layouts for the numeric keypad? Or the plastic overlays for the keyboard? Time marches on - I've been to customer sites where they have all the various lists of mouse syntax taped to their terminal. But enough rambling... I've seen projects who feel they got a lot of benefit from FI's despite the cost. Perhaps the emphasis these days on things like continuing process improvement are a better way to go. Demming's work sure does seem to apply much better to things like assembly lines instead of coding. Maybe the answer is that coding should be more like assembly work - take lots of pieces you know to be good and plug 'em together with a bit of flash on the top to get a product. It's the way most other industries work, after all. I do have a pair of comments on the FI process itself: 1. The Formal Inspection process didn't go through a formal inspection of itself. There were a couple of problems in the Inspectors Handbook - and initiates would ask when they found the problems if the process had been inspected. "No." wasn't the answer they expected to hear ;-) 2. Moderators sent in statistics on the number and types of problems found - without identifying the projects involved - to the originators of the FI process at Digital. They were supposed to give us feedback and statistics on the FI effort and its benefits, but we (I) never heard a word. Trace - A trained but rusty from lack of use Formal Inspection Moderator
1761.41	Think for yourself	TLE::AMARTIN	Alan H. Martin	`Wed Feb 12 1992 11:09`	80
	Re .31: > I would be interested in talking to any group that has actually used > formal inspection to instrument a software delivery process, provide > feedback, change the process and measure the results. I'll bet a > hamburger that no software group in DEC has closed the loop. What formal inspection meant to me as a member of the Fortran-10/20 team: a better way of conducting the reviews which we already performed. I checked my performance review self-assessments yesterday, and I've attended 31 formal inspections (moderated over half a dozen). I (and others) have seen the following benefits from the process: Inspection discipline before running the meeting made the review of material go far smoother. We were fairly certain that everyone had actually read the material all the way through before the meeting started. The material had been better prepared for readability - listings with change bars; no raw printouts of source files made at the last minute. Inspection discipline while running the meeting made the review of material go far smoother. The material (Bliss-10 and Macro-10 code; specifications and designs; regression test applications, scripts and results) was covered in a much more linear fashion - everyone concentrated on the same section of code. Far less of everyone's time spent on nits which didn't impact the product in a way important to the team as a whole. Inspection discipline after running the meeting made the defects discovered more likely to be addressed. When someone else has an orderly list of all the problems found, it's harder to blow off fixing them. (My experience in inspections makes it very hard for me to understand how the problem recording process could present significant overhead compared to a chaotic code review; for all I know, the recording methodology saved time compared to merging in changes from a dozen bled-upon listings. And if it took us 15 minutes total to ship copies of our pent-up inspection reports to Lou Cohen for potential study, I'd be surprised. If all the data collection never closed any loops whatsoever, I would still have wasted more time making coffee in any given year when jerks leave all the carafes empty). Team understanding of the product's internals continued to increase over time (even across components), as it had when we merely used traditionally chaotic code reviews. In my experience, no amount of unit and regression testing will cause half a dozen people to learn their product's internal simultaneously. The best you can hope for when relying solely on testing (as you endorse) is for the code and test authors to know what's going on. My experience with separate test authors is that they generally only have the time to write black-box tests, and learn nothing whatsoever about their product's internals. Among other things, this can make testing a career dead-end for otherwise capable engineers. "We can't have Bob do any coding - he's just a test person and doesn't understand the product". Conformance to coding standards continued to increase over time, as it had when we used traditionally chaotic code reviews. However, it takes far less time to note that a code segment is not in conformance and then move on, when one is secure in the knowledge that the fact will be acted upon. So, the product became more maintainable and evolvable over time. (I know of more than one group that claims to have a code review process in place, but keeps evidence of any review well hidden). Establishment of a more formal process for review of documents meant they were more likely to be reviewed. This caused product reliability to increase. And finally, formal inspection, like chaotic reviews, exposed me to common error modes which I then attempted to avoid in my writing and coding. That is a closed feedback loop, with no additional "instrumentation" necessary. Note that very little of the above involved the assumption that K.O. would get a clue about leading the whole corporation towards improved product quality. The fact that one attends these classes doesn't mean that one has to buy in to the whole program, and then sit around on a toadstool and curse when everyone else carries on with business as usual. Try the stuff out, adopt what works and discard what doesn't. The fact that the corporation as a whole still hasn't got its act together is a piss-poor excuse to blow off the techniques available to us. "Formal-Inspection-the-party-line" can be morally bankrupt within the company, yet "Formal-Inspection-as-you-choose-to-practice-it" can be the best single process you adopt all year. /AHM
1761.42	Attitude is fundamental	PLOUGH::KINZELMAN	Paul Kinzelman	`Wed Feb 12 1992 11:12`	24
	To me, attitude is more fundamental than the logistics of how to support a positive attitude (via 6sigma, Deming, or whatever). If the group or management and workers have no integrity and no interest in excelling (as someone gave examples previously of this), no process will work. If management and workers work as a team, miracles can happen. You can't legislate and process attitude into people. Mapping the process can sometimes be useful, but it's not a panacea. It depends on people's integrity. In my particular case, I went to 6-sigma and could not find a way to fit what I saw into my particular job. I produce models and a verification process for a customer (internal engineering). I could exhaustively debug what I do before I let the customer have it but it would be useless because it would be too late. Better to release it in a non-finished form to engineering and work with them to fix bugs rather than making them wait for attempted perfection. But my attitude in working on it is to "delight" engineering. Thus, my "sigma" is probably pretty low. Schedule pressure can reduce the need for "perfection". In my case, there's no time to get my "product" to perfection before it's needed. My attitude of trying to delight the engineer counts a lot more than figuring out some process to produce metrics. I and the engineer know when it works or doesn't work. The engineers I support are generally delighted with what I do, bugs and all.
1761.43		STUDIO::HAMER	complexity=technical immaturity	`Wed Feb 12 1992 11:17`	41
	I disagree with several things that have been said about quality and six sigma. I'm speaking from my experience with six sigma for hardware products, I am not familiar enough with Six Sigma for software. Six sigma is emphatically not back-end dominant. It is the first of all the so-called flavors of the month that really comes to grips with the fact that 80% of all cost and 80% of all quality is determined by the design of a product (and in hardware, "design" means before a prototype is built). It is an overall approach to work that begins with the, unfortunately, radical notion that customer satisfaction must be the judge of goodness in all jobs at all levels of the entire organization. I see six sigma as a context, a source of integration that lets me say "oh yeah, now I see how this JIT, benchmarking, concurrent engineering, etc. should fit together." Taking seriously the notion of Cp is a powerful reason for involving more disciplines in product design. Using customer satisfaction as a measure of quality provides a real clear reason for really using QFD or contextual inquiry. Count opportunities for defects in a product or process and you get the process/product simplification bug real quick. Six sigma provides a clear business motivation to adopt and follow, or to reject as not relevant to the measurement that really counts, the best practices that get lumped derisively in "flavor of the month." Six sigma is not a club to beat manufacturing with. That it may be used as one is symptomatic of the precisely the reasons we need six sigma: we don't have a "manufacturing problem," or a "design problem," or an "organization problem." We have a Digital problem -- one stock price, one reputation, one enterprise. re: Perfection. I think it can be reached. A product designed to satisfy customer requirements for a manufacturing process aimed always at reducing variation can produce 100% good product. I can hear the red herrings flopping in the bottom of the boat: "it costs too much to squeeze out that last defect." As if we were staring that problem in the face. John H.
1761.44	ANY process, manufacturing, SW design, and so on	DOBRA::MCGOVERN		`Wed Feb 12 1992 11:56`	19
	I have a basic question regarding 6-Sigma. My understanding of process control came from writing DEC Standard 084. That standard explicitly encourages use of Ishakawa Diagrams, Tecughi's Design of Experiments, and other methods to develop process parametric control. The idea is to develop a process, determine what parameters cause effects to it, determine what are the optimum settings for these parameters, and then to run the process while controlling the parameters within the stated limits. The hypothesis is that if you properly define the process and control what affects it, you can maintain high-quality output. This approach makes sense to me because it contantly feedsback what the process is doing, gives places to check for CAUSES of defects, and is open to reworking of the process to improve it. Is this what 6-Sigma is talking about? MM
1761.45	People as parameters?	VAULT::CRAMER		`Wed Feb 12 1992 12:27`	21
	re: .44 "The idea is to develop a process, determine what parameters cause effects to it, determine what are the optimum settings for these parameters, and then to run the process while controlling the parameters within the stated limits. " Given that software development, as done today in DEC, is closer too an art than a science, can you explain to mee how you parameterize the development process? How do you quantify creative inspiration? I am not being snide. I really do want to know. All attempts at controlling the development process seem to founder on the shoals of personallity conflicts and foibles. The only viable solution that I have seen is when an elite, either person or small group, is seen by everyone invloved to be so good that they are unquestionably deferred to. That is a very rare occurance. DEC doesn't do authority, where an elite is named and they can make and enforce standards. So what is the answer? Alan
1761.46		SQM::MACDONALD		`Wed Feb 12 1992 15:43`	33
	Re: .36 >Then we should not be bothering with six sigma, TQM etc. until we fix >the more basic problems in DEC. All these quality assurance methods >are doomed to failure and will get an undeserved bad reputation until >the management pattern is changed. > >Until we can develop a stable organization with measurements that are >directly related to the stated goals of the company all the quality >programs in the world will do nothing more than feed our delusions. Six Sigma, TQM, etc. can provide the momentum necessary to make these changes because they help to identify the data that proves we need to do this. >Someone in here mentioned that Deming does not believe in merit pay. How, >then, does he avoid the well known problem of labor sinking to the lowest >common denominator. The "heck, Joe is goofing off and gets the same pay >I do; why should I work hard?" syndrome. It is a known, demonstrable fact >that letting slack workers get by is bad for morale and productivity of >workers that had been doing good work. Yes, that is correct about Deming. If you want to know read his book Out of the Crisis or the book about him The Man Who Invented Quality. He'll state his case for this better than any of us will. Just for example, however, I think Deming would say that a not infrequent contributor to Joe's goofing off is a work process that he can't really succeed with, but check with Deming. He's successfully convinced quite a number of companies that he is right. Steve
1761.47		SQM::MACDONALD		`Wed Feb 12 1992 15:44`	8
	Re: .37 This is not a debate about Six Sigma vs. Deming. Much of the philosophy of Six Sigma got its start with Deming. Steve
1761.48		SQM::MACDONALD		`Wed Feb 12 1992 15:55`	43
	Re: .38 >Just because you and I don't agree does not mean that I do not have the >facts, so this rather arrogant comment does not cut ice with me. In >point of fact, I have gone to significant lengths to find out about >six-sigma, and have drawn some conclusions, not all of them nice. I am >indeed negative about some of its aspects, the most important of which >is the EMPHASIS, placed by practicioners, on the back-end of the product >development process. First of all lighten up. That comment was not directed at anyone in particular. It has become clear to me that people, not only or even you, have formed their opinions from hearsay. But since you go on, it is clear that you don't have the facts straight. It may be a "fact" that particular practitioners you have encountered have placed emphasis on the back end of the development process, but that is most certainly not "fact" about the overall Six Sigma approach. >In general, we need less of the "formal inspection" and statistical >analysis, and more of the up-front product and process development. >Yes, I know that QFD is touted in the overall six-sigma approach. But >so is everything else. But the plain fact of life here is that QFD is >only implemented as a Requirements Analysis methodology, and taken no >further. This fact alone dooms six-sigma to ultimate failure. Six Sigma as I understand and teach it and as I see it being practiced does just what you suggest but with one difference. Without methods like formal inspection and analysis used further along in the process you aren't going to know if all the hard work you've done up front is going astray. Ray, we've had this battle before in the Phase Review Process notes file. Neither Six Sigma nor TQM in any way say that what you are proposing about QFD is wrong. In fact if you are having success satisfying your customers then that is really all that is important. The only thing I see missing and perhaps it is missing only because you don't appear to have mentioned it is measurement of your results to ensure that customers are satisfied. Perhaps you'd like to comment on that. Steve
1761.49		SQM::MACDONALD		`Wed Feb 12 1992 16:23`	22
	Re: .41 This is on the money. There's nothing like having used it and gotten results for a testimonial. Re: .43 Thanks, John. Some very eloquent points about Six Sigma. Re: .44 > This approach makes sense to me because it contantly feedsback what > the process is doing, gives places to check for CAUSES of defects, > and is open to reworking of the process to improve it. > > Is this what 6-Sigma is talking about? Precisely! Steve
1761.50	Can't we do anything right?	STAR::DIPIRRO		`Thu Feb 13 1992 08:47`	30
	My problem with all this is how we go about implementing change at DEC. TQM looks like a grass-roots effort to me, and this piecemeal, bottom-up approach is contrary to what Deming proposes. He says that leadership and direction should come from the top, with a clearly stated vision and goals as to what is important to the company. If quality REALLY is important, more important than, say, the schedule (which I've NEVER seen by the way), then the "system" needs to change from the top down to accommodate it...And the "system" includes our work environment, reward system, development methodologies,...everything. It should even show up in your performance review. Now I hear a lot of talk about quality, more now than ever before at DEC. I hear that top-level management is really behind it. Then I see piecemeal training and implementation at the very lowest levels. This will not accomplish anything in my opinion. One example, used frequently in this note, is formal inspections. By itself, this is not expected to solve software quality problems. However, I was told in a previous job that we were now going to be doing formal inspections and that this would fix our quality problems. We had people trained to do this, and off we went. After two years or so, we determined that there was a negligable effect on product quality. However, there was a significant effect on everyones' nerves. The process was a haven for nit-pickers and was great for finding spelling errors in the comments, but we found that "normal" design reviews and occasional code reviews were much more effective towards producing a quality software product. Every single person involved with formal inspections on this project said they would rather leave the company than go through that again. This was an example to illustrate my point. I'm not even knocking formal inspections or 6-Sigma (well, maybe a little). Deming's message is pretty clear. If we believe in it, then why don't we do it right for a change? It's ridiculous the way we go about implementing some things in this company. If we're not going to do it right, then we shouldn't do it at all!
1761.51		SQM::MACDONALD		`Thu Feb 13 1992 08:59`	35
	Re: .50 I agree with much of what you say. Not only does Deming say that there must be top down leadership, but also the more prominent TQM gurus, like Shoji Shiba, also say that it must be so. Shiba, in fact, has done quite a lot of consulting work here in Digital. At a talk in The Mill, he stated that without top management buy-in AND participation that the effort to achieve TQM will eventually fizzle. Of those companies that have tried without top management leading the way, the longest it seems to last is 2-3 years and that is only when there are some very strong advocates pusing until they wear out. >This was an example to illustrate my point. I'm not even knocking >formal inspections or 6-Sigma (well, maybe a little). There may have been any number of reasons why formal inspections did not work well in your past experience. Some of what you say seems to hint at what some of the causes might have been. >Deming's message is pretty clear. If we believe in it, then why don't --------- >we do it right for a change? It's ridiculous the way we go about ---------------------------- >implementing some things in this company. If we're not going to do it >right, then we shouldn't do it at all! You've asked the $64,000 question! If anyone had the answer to that we'd be implementing that way right now and not talking about it! If you get any ideas, there'll be lots of us eagerly listening. ;^) Steve
1761.52		FIGS::BANKS	Vice President in charge of VMSMail	`Thu Feb 13 1992 10:41`	44
	Management really behind quality? Once upon a time, a manager took some time out from his continuous barrage of re-orgs and compiled a list of the buggiest products within his domain, using a metric which I believe to be about as good as any. He did this in the name of quality. He hoarded this list, using it mainly to wave at meetings, in a fashion somewhat reminiscent of McCarthy and his list of known communist sympathisers. It wasn't until they set this manager out to other pastures that anyone saw the contents of the list. The new management decided to start a bold new comprehensive program to address the quality problems as documented by this list. All in the name of quality. The thrust of this quality project was to patch and band-aid the products on that list to "fix" most of the known bugs. A small team was formed, presumably free of the shackles of process to address these problems over a six month period. Ownership of this team was tossed back and forth between two peer level managers over the course of the six months. It turned out that the team wasn't so free of process, after all. It turned out that the team wasn't staffed by that many people. It turned out that the team could (and did) make measurable progress in that six months, but couldn't really address as many of the "bugs" as would have been desired. The VP says "We want quality". The leader of this team says "Ok, we need people and funding". The management between the VP and the team leader says "You mean this is going to cost????" The team ceased to exist. The members of the team went their own ways. Some (or many) of them decided to keep working on those products to try to catch up on all those defects. Ironically, in making this a full time pursuit, these people put themselves in the position of having twice the amount of process that they had before. Enough that it can take a week just to get a few line bug fix implemented. Yes, I hear LOTS of management talking about quality. I see the occasional manager taking some halfhearted measures to do something about it. I see precious few backing the words with any real substance. And, this assumes that fixing a batch of bugs really "fixes" the quality of the product. Quality at DEC seems like a buzzword, intended mainly to be vitamins for resumes. I still don't see any real evidence of real high level comittment.
1761.53	Don't sweat the small stuff . . .	CAPNET::CROWTHER	Maxine 276-8226	`Thu Feb 13 1992 11:33`	18
	Perhaps we need to work this at DEC like burning the candle at both ends. There are senior managers who understand and there are also folks like us who understand. If both ends work for quality and demonstrate results then maybe the rest of senior management will come around. We have many islands of excellence in this corporation, many real positive stories. But if we continue to quibble about whether its 6 sigma or QFD then we can't make any forward progress. I believe that each of us in our own jobs needs to determine how to do that job with quality (or Quality) and we have to do it. And we need to do it, if possible, by making our managers look good so they'll let us keep doing it. This is not rocket science!! Technical people are bogging down in the statistics and the methodology - don't - just get started and do what you think is best.
1761.54	Hearing what we want to hear...	WLDBIL::KILGORE	DCU Elections -- Vote for a change...	`Thu Feb 13 1992 17:07`	11
	re .49 .31 contains negative comments about formal inspection, from someone who has used it a lot. .41 contains positive comments about formal inspection, from someone who has used it a lot. To applaud one and dismiss the other may strike close to the heart of what is wrong in DEC today.
1761.55	Remember "Do the right thing!" ?	SWAM2::KELLER_FR		`Fri Feb 14 1992 09:57`	16
	re .54: I couldn't agree more; there are some real closed minds and they seem to take uncommon delight in accusing people that don't agree of "intolerance". What it all comes down to is that we are the company and our individual actions are what, in the end, defines what DEC is or isn't. So if we each in our own sphere do the right thing (remember when you heard that all the time???) then DEC will be seen in that light. If we don't do it, nobody will. So let's start a revival of the "Do the right thing" ethic wherever we can and let's see what happens! Fred :^)
1761.56	I can do that . . .	CAPNET::CROWTHER	Maxine 276-8226	`Fri Feb 14 1992 12:38`	3
	re .55 Amen brother!!!!
1761.57	Mars Inc. and quality... ingrained in the company...	WAYHIP::WOLFF	Greg Wolff, MISG, ICS::WOLFF, 223-0855	`Mon Feb 17 1992 09:56`	168
	I think that this article from the Wall Street Journal should be read by those involved in this discussion. Here is an example of a company that seems to be following the spirit (if not the letter?) of Mr. Deming's advice. Greg <><><><><><><><> T h e V O G O N N e w s S e r v i c e <><><><><><><><> Edition : 2516 Monday 17-Feb-1992 Circulation : 8109 VNS TECHNOLOGY WATCH .............................. 141 " Please send subscription and backissue requests to CASEE::VNS VNS TECHNOLOGY WATCH: [Mike Taylor, VNS Correspondent] ===================== [Littleton, MA, USA ] Quality Control From Mars Forget the Japanese. Forget the Germans. The best lessons on management come from Mars. No, not the planet. But the multibillion-dollar, world-class company known as Mars Inc., a leader in candy, pet food, rice and other products. A secretive, closely held company like no other in the U.S., Mars is as successful as it is unconventional. As someone who worked as an executive there, I can speak from experience. Being hired into Mars from a conventional, publicly held company is akin to an earthling trying to survive on the red planet. You can survive only by letting go of most of the beliefs and assumptions learned in a normal business environment. The first visible symbols of this alien culture are the absence of assigned paring spaces, private offices or even partitions between desks. Time clocks are at the door and everybody punches in, including senior executives and the billionaire owners. Punch in on time and get a 10% punctuality bonus. Walk into any Mars subsidiary world-wide and see the same office layout of concentric circles, with the president and his (or her) staff at the center and their direct subordinates at the next circle, their subordinates at the next, and so on. Operating in close proximity to each other in the fish bowl at the center, the senior staffers are totally visible and accessible. When something important happens in the business, watch the president call the senior staff to his desk. At the conclusion of the impromptu meeting, observe the staffers going back to their desks to call their departments together for their own impromptu meetings. Like an army of ants going hither and fro, the office is soon a buzz of sound and activity. Communications are fast and open. Memos aren't written and electronic mail goes unused. Since Mars offices are always connected to a plant, it's an easy walk over to the factory, where the most wondrous sights await you. Everyone is in white uniforms and bump hats-- managers and workers alike. The plant is spotless and shiny, the high-speed lines are marvels of efficiency, and the high-paid, non-union employees are loyal and proud. On any particular day, one of the Mars brothers who own the business is likely to show up at a subsidiary. He flies in from his Virginia office, where a headquarters staff of less than 50 a far-flung, 25,000-employee enterprise. Wearing scuffed cowboy boots and a wrinkled shirt, he parks a midsized rental car in the far end of the employee lot and walks toward the office. Unlike most chief executives, he does not head straight for the subsidiary president to review the quarterly results. Instead, he grabs a white smock and bump hat and heads for the factory. You will hear him screaming if he finds unclean or unsafe conditions. And woe to the plant vice president if less-than-perfect product is coming off the line. Quality is an unrelenting obsession at Mars. One example of that obsession is a fear of "incremental degradation," a term used by Mars to describe what can happen by using cheaper ingredients. Rather than replace a high-priced ingredient with a cheaper one, even if taste tests show that the consumer would not notice a difference, Mars will forgo the extra profits instead of risking an incremental degradation of the quality of its products. The latest in statistical process/quality control charting may not be seen on the walls, but observe in the factories the constant product inspection and tasting-- even the tasting of pet food. Watch a whole production run of candy bars be thrown out because of barely noticeable nicks in the chocolate coating. Better yet, follow a Mars salesman on a supermarket visit. Watch the individual discard a whole display of product because it is getting too close to the date on the freshness code. Look for someone with quality in his title and come up empty-handed. Look for people concerned about quality and come up with the entire work force. Closer inspection of Mars's operation reveals huge market shares, obscene profits and such high productivity that the business operates with 30% fewer employees than its closest competitor. With results like these, you'd think that Mars must have the best merit and incentive programs in America. But the conventional wisdom does not hold true in the world of Mars. All Mars employees are on a step-increase system, getting the same annual adjustment as everyone else. Employees at Mars have something more motivating than phony merit and incentive systems: a high degree of job security and pay that is pegged at the 90th percentile of the compensation offered by other premier companies in the world. Moreover, by operating with only six levels and paying all vice presidents approximately the same salary regardless of the function they head, Mars finds it easy to transfer people from business unit to business unit and function to function. Someone heading up human resources today in a billion-dollar domestic business may be heading up manufacturing tomorrow in a half-billion-dollar domestic European business. It is a rare general manager who has not done a tour of duty in manufacturing or marketing in at least two business units. As a result, key managers know the business so well that a consistent organizational culture and operating style can be maintained world-wide with few formal rules and procedures. Financial and business measurements are few but powerful. The most powerful is ROTA (return on total assets), which, in a unique equation, takes into account inventory turns and asset utilization. This measurement, combined with valuing equipment at replacement cost instead of book value, gives managers an incentive to replace equipment with the latest technology. At a Mars pet food plant I once visited in Germany, a perfectly good can-filling machine was replaced by a state-of-the-art machine, even though the additional capacity wasn't needed at the time. Is there a dark side to Mars? Yes. Just as the planet is a harsh environment, the company can be a stressful place, particularly for higher-level managers who must deal with the impulsive nature of the owners. I remember the finance vice president in a subsidiary who decided to buy some nice wooden desks. One of the owners came by one day and began to fume when he saw them. "Would you ever buy a more expensive desk than your boss has?" he asked me, as he sat down just waiting for the VP to walk in. When the VP arrived, the shouting began. If it had been anybody other than an owner, it would have been devastating. But because the culture of the organization is so effective, there's an aura about the people who own the company. These occasional outbursts become ingrained in the mythology of the company and serve to reinforce the corporate philosophy. Companies like Mars can force us to face the possibility that we are wrong about what a true quality culture looks like, about how business should be measured, about how people should be paid, about the role of senior management, and about the development of management talent. Instead of looking overseas for solutions to our problems of competitiveness, maybe we should look to another planet for the answers. The Mars Voyager is waiting for you on the launch pad. The Wall Street Journal, Vol. CXXVI No. 18, Monday 27-Jan-92 "Manager's Journal" by Craig J. Cantoni Mr. Cantoni is vice president of human resources and logistics at J.M. Huber, a $1 billion family-held company in Edison, N.J. {contributed by E.V. Pons} <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Please send subscription and backissue requests to CASEE::VNS Permission to copy material from this VNS is granted (per DIGITAL PP&P) provided that the message header for the issue and credit lines for the VNS correspondent and original source are retained in the copy. <><><><><><><><> VNS Edition : 2516 Monday 17-Feb-1992 <><><><><><><><>
1761.58	Half-assed is probably better than nothing	STAR::DIPIRRO		`Mon Feb 17 1992 11:26`	10
	Interesting article about Mars...not that that work style would suit me very well, but if it works for Mars, who could argue? It also reinforces the statement that quality must come from the top. Reply 53 illustrated my point perfectly. That is how we do things at DEC - grass roots and bottom up. Don't get me wrong, it shows that people really care and want to do the right thing for the most part...It may even work to some degree, improving the quality in certain areas despite the lack of a comprehensive program. It just won't be as effective as the top-down approach Deming describes and that other companies are proving works.
1761.59	Increas price, decrease cost or increase market share ???	ULTRA::BURGESS	Mad Man across the water	`Mon Feb 17 1992 11:35`	9
	re Mars I found the "incremental degradation" philosophy to be quite interesting. For some reason "cost reduction ECOs" kept coming into my mind as I read that part. R
1761.60	let 'em eat DESTAs	SALSA::MOELLER	Psst.. 3 day weekends-Pass it on	`Mon Feb 17 1992 18:14`	5
	Me, too, Reg.. as I read the section about 'incremental degradation' of products I thought about the lack of Thinwire connections on the new RISC workstations.. must've saved as much as $1.50 each. karl
1761.61		TLE::WINALSKI	Careful with that VAX, Eugene	`Mon Feb 17 1992 23:46`	5
	RE: .59 For some reason, VMS releases kept coming into my mind. --PSW
1761.62	who says you can't buy loyalty?	REGENT::POWERS		`Tue Feb 18 1992 09:00`	13
	> Employees at Mars have something more motivating than phony merit and > incentive systems: a high degree of job security and pay that is > pegged at the 90th percentile of the compensation offered by other > premier companies in the world. Doesn't this say it all? (Obviously not, but it bears on other things: Did the person who let those nicks occur in all those chocolate coatings fear for loss of a 90th percentile paycheck? If the owners have no compunction about chewing out a VP for "having a better desk than his boss" that may be the case.) - tom]
1761.63	Random thoughts from the Field	HOTWTR::EVANS_BR		`Tue Feb 18 1992 16:16`	14
	Interestingly enough, my initial reaction to the Mars memo was shock and amazement. That strict regimentation is totally counter to my personal style of work... but if we really value the Digital "style" of work, we all need to show that it is every bit as productive (as measured monetarily) as the Mars Methodology. I'm not too sure that we have been. Also, can one apply the Mars Methods to the more creative techniques of making computers and the software?? I think some of the thinking is good (quality, etc), but the rigidity is typical of well established clearly understood manufacturing methods (eg... they don't change for 10-50 years) which makes me wonder if this kind of structure would survive in our industry.
1761.64	Chocolate chips and alpha chips	RIPPLE::PETTIGREW_MI		`Tue Feb 18 1992 19:54`	26
	Developing software is not the same business as making candy bars. The behaviours and management policies that succeed for the MARS company are not likely to be successful in DIGITAL, and vice versa. It's important to understand why certain behaviours succeed, and what the limits are to that success. A production company like MARS will make thousands, or hundreds of thousands of units per month. All of those units must be identical. How many times do we build VMS release 1.0? Even if you count each product release as a unit of the same product, there are not enough units for the development processes to completely stabilize. And the process will be different for different products. Repetitive and Continuous Process Manufacturing businesses depend on stable processes and controlled environments. Processes must be well understood. Effective control measures must be available to keep process measurement within close tolerances. Once established, a process can be continued indefinitely. A process output can be exactly described. Software development is a business where you only make prototypes. It is more similar to the office construction business or the residential development business than to any volume manufacturing business. The lessons to be learned from the MARS company are very limited in scope for the software development side of DIGITAL. The hardware manufacturing side of DIGITAL may have many parallels with a volume manufacturer such as MARS.
1761.65	Manufacturing software as well as hardware	STAR::ABBASI		`Tue Feb 18 1992 23:11`	24
	ref .-1 I dont see why there ought not to be more similarity in the process of building software and hardware, in hardware , Engineers dont invent every chip every time they want to build a system, they usually pick up chips off the shelf, and plug them together , this pin goes with that pin, etc.. we in software seem to write allot of new code every time we write a new software system, we dont seem to be very good at software re-use. If we can be better at software re-use (at the company wide level, not at only at the project level), we can make tones more money by saving time, better quality , reduce testing times, less maintenance etc.. we should have a company wide software libraries, that every one can access and pull from it the right software components, it should be catalogued and well specified, and portable. ok, that is the end of my speach.. Thank You. /nasser
1761.66	what keeps your interest?	SGOUTL::BELDIN_R	Pull us together, not apart	`Wed Feb 19 1992 09:17`	14
	re .63 and .64 I once interviewed for a position with a large health care multinational subsidiary. They had a very good quality conscious operation which had been producing the same products for over 75 years with perhaps 5 changes in technology and/or process. When I thought about it, I realized that a large part of the interest in my job is the ebb and flow of product startups, transfers, and end of life. I decided that two (rather simple, but lucrative) products would not hold my interest for long. So, here I am, for the time being, Dick
1761.67		SQM::MACDONALD		`Wed Feb 19 1992 09:35`	44
	Re: .54 >Re: .49 -< Hearing what we want to hear... >- > >.31 contains negative comments about formal inspection, from someone >who has used it a lot. > >.41 contains positive comments about formal inspection, from someone >who has used it a lot. > >To applaud one and dismiss the other may strike close to the heart of >what is wrong in DEC today. FLAME ON (I guess I just got up on the wrong side of bed today) Wait a minute. Just because I didn't respond to .31 does not mean I was "dismissing" you. In fact your .31 was a response to a note of mine simply repeating what you had already said. I HEARD YOU ALREADY. We had exchanged views and I didn't see the need to keep hashing it back and forth so how is that hearing only what I want to hear? Just what is your point here? Are you looking for a debate over this? I thought this was just an exchange of views. I fail to understand the reason for the smarta** comment. In fact, you began one note with words to the effect that you'd really like to see where formal inspections are working. I invited you to contact me offline and I'd be happy to point you to places in DEC where they are working well. I haven't heard a word from you. Frankly it seems what's really going on here is that I'm not hearing what YOU want me to hear. For the record, I agree with you about the environment that is required to make formal inspections helpful, but I disagree with your points about formal inspections themselves. You wonder what's wrong with DEC today? Not being able to exchange views without a lot of snide commentary is certainly part of it. When you point the finger, there are 3 pointing back at YOU. Get a life. FLAME OFF. Steve
1761.68	Learn from comparable examples	RIPPLE::PETTIGREW_MI		`Wed Feb 19 1992 13:57`	18
	RE:65 (Nasser) Hardware manufacturing is different from software development because manufacturing is all about the consistent replication of a single well-specified product. Software development is all about creating a product from ill-defined requirements and building (or growing) one unit of that product. Software development is similar to hardware (prototype) development. It is not very similar to manufacturing. Successful behaviors in a manufacturing business have limited application in a development business and vice-versa. Individuals commonly re-use their own code and design ideas on subsequent projects. Clever people may use other's code or design ideas as well. The truly inspired ones actually give credit to their sources. Your wish for "reusable code libraries" may already be reality in a form you have not recognized.
1761.69	Large clash over small effects	RIPPLE::PETTIGREW_MI		`Wed Feb 19 1992 14:12`	15
	RE: 31,41,54 (Squabbling over code inspection) The most critical process in software developement is the definition of product requirements. This is also the process that is least well understood and has the most variability. The attempt to define requirements may change them. The sequence in which requirements are defined may alter the definitions. The demonstration of a product that satisfies some customer requirements may change the perception of others. Code inspections, whether effectively conducted or not, are very time-consuming, and have comparably little effect on product functionality. Code inspections may have minor effects on product reliability, or performance. Inspections often have a major effect on developer's egos.
1761.70		VIRTUE::MACDONALD		`Wed Feb 19 1992 14:52`	27
	Re: .69 -< Large class over small effects >- If what you are trying to say is that having a good process for defining requirements has a larger overall effect on quality than do formal inspections then I agree with you 100%. Formally inspecting everything in the process won't make up for lack of good requirments. If you are saying that formal inspections by themselves provide very little benefit then I believe you are wrong. Given good requirements, formal inspections are a significant contributor to ensuring that you deliver against those requirements. We are not talking "code inspections". Code is only one thing that might be inspected. Everything produced during a project is a candidate for formal inspection. A formal inspection is a disciplined process for ensuring that some thing (i.e. code, product requirements, functional specs, design specs, test plans, etc.) in fact addresses or delivers what it was intended to. It's the best way we know of to ensure that if problems are developing that we can still correct them when it is cheap to do so. If there is reason to continue perhaps we ought to take this offline. Steve
1761.71		FIGS::BANKS	Vice President in charge of VMSMail	`Wed Feb 19 1992 15:52`	20
	I don't think I've ever seen a sane software requirements definition in the entire time I've worked at Digital. For starters, people rarely know what they really want until the coding's halfway done. Then, people change all kinds of requirements in mid-coding effort. Then, when the schedule starts getting tight, all sorts of stuff is thrown overboard so that the schedule date will be met. (For the life of me, I don't see how you can claim that you made the schedule date when you're delivering something that's substantially different from the originally committed requirements). Given the continual change in deliverables, and the pervasive notion that "Well, this is V1. We just have time to get it to work. We can fix it/make it faster/ make it better/rewrite it in V2", it's no wonder that quality stinks. (And, V2 always seems to be motivated by all the same garbage as V1 - there's really never time to go back and fix/rewrite/speed up/make better the garbage shipped in V1.) I'd have to agree that defining requirements is a process that needs lots of work (and that can yield a good increase in quality).
1761.72		VIRTUE::MACDONALD		`Wed Feb 19 1992 16:15`	28
	Re: .71 >I don't think I've ever seen a sane software requirements definition in >the entire time I've worked at Digital. > >For starters, people rarely know what they really want until the >coding's halfway done. Then, people change all kinds of requirements >in mid-coding effort. Then, when the schedule starts getting tight, >all sorts of stuff is thrown overboard so that the schedule date will >be met. (For the life of me, I don't see how you can claim that you >made the schedule date when you're delivering something that's >substantially different from the originally committed requirements). This squares with my experience precisely. I think that the reason why people rarely know what they want until the code is half done is because they jump into the code with what in reality is a half developed idea. We do this to ourselves time and again. The upfront work of fully developing the idea/requirements is frankly not fun work. It is painstaking and difficult and not as much fun as mucking about with code. A good first step would be for us to admit to ourselves that we have been avoiding the hard work of developing good requirements and that we have stop doing that. Steve
1761.73	What is the real problem?	CAPNET::CROWTHER	Maxine 276-8226	`Wed Feb 19 1992 16:19`	11
	I come from the IS world many moons agree and while I agree with the comments about software, I can't help but wonder why we can't figure out how to solve the problem of the changing spec. Is it because we don't prototype and the development period is too long? Is it because we don't ask the right questions? Is it because we make too many assumptions? Instead of blaming users and "them" why don't the folks most affected do a root cause anaylsis of some sort to try and find the answer? Or perhaps we might listen to the "Voice of the Customer" and give them what they want instead of what we want to give them.
1761.74	we'd better learn	TOOK::SCHUCHARD	i got virtual connections...	`Wed Feb 19 1992 16:35`	25
	If you abstract a problem enough, you can anticipate requirement changes and minimize their impact. In this day of commoditizing software bodies there is no longer any valid presumption that you have a quality team. You cannot afford to skip some kind of review of designs/data structures/alogrithms. The desperate move to try and come up with valid object-oriented languages systems is no more than yet one more attempt to force well written software, without having to hire/depend on quality engineers. Life would be much simpler for a Development manager if he/she could just hire more bodies to get the product out quicker. Hiring more bodies is usually a very reliable prescription for disaster. The problem will become more mangled just by providing enough work to keep them happy, instead of a few talented folk looking for a simpler solution. Of course that has never stopped development managers from trying. With the persistence of this environment, it is imperative to assert more quality control, even at the expense of bruised egos. Ever wonder why the 1-2 man shop consistently gets the high quality product out in 1/4 the time our mega-bodied disasters splatter themselves in the marketplace?
1761.75		FIGS::BANKS	Vice President in charge of VMSMail	`Wed Feb 19 1992 16:37`	37
	I tried prototyping something once. (Actually, I've TRIED it many times.) The architecture was, well, a bit of a handfull. I didn't begin to understand what was going on in there, and I couldn't find anyone else who did. There were a bunch of issues, but I couldn't get a firm grasp on any of them without an idea of what was going on underneath. So, I was left with a problem: I didn't fully understand what we were doing, and I knew that the architecture itself would be in a state of flux until we had a firm grasp on what was possible. I didn't know what was possible, because, ... well you get the idea. In the mean time, I had to write a design spec. A design spec for something I didn't fully understand. So, I sat down with the architecture specs, and taking them as literally as possible, I decided to build a prototype, just to see what it was and what it was supposed to do. The idea I had was that given the prototype, I'd know what the pitfalls would be, how I'd really want to design it, where I should be careful, and how to make it work - extensibly - without being a layered crock. I did that, and really ended up achieving all my goals. I finally understood the architecture, the product, where it could go wrong, and how I wanted to implement the real product. So, where did it all go wrong? Well, they went (in a period of a couple of weeks) from wanting me to work on a design spec to wanting to ship yesterday. (No, I wasn't behind schedule. They just changed their minds.) I was told to keep working on the prototype. They shipped the prototype. And, now they want to know why the design is so simplistic, etc. In effect, they want to know why it sucks. Well, it's a prototype, that's why. It wasn't supposed to be good. It was supposed to be a learning tool to test ideas. I still cringe.
1761.76	Change Management..what an idea!	DENVER::DAVISGB	This note is legal tender	`Wed Feb 19 1992 16:39`	20
	Re :Note 1761.73 >... I can't help but wonder why we can't figure > out how to solve the problem of the changing spec. Coming from a Digital Services (EIS, Software Services, whatever) perspective, our problem is that we can't manage change. We engineer software for customers like we're building a tapedrive (piece of hardware). At the beginning, we have a functional spec (hopefully) and we kill ourselves to stay rigidly to that spec. Change upsets Digital's applecart. Fixed price means fixed functionality. Which is part of the reason why EDS, Anderson, and all the others are so successful. They do value-based pricing. They don;t have a line item that says "X" consulting skill at $X. They price according to what it's worth to the customer. When changes occur, they use the change to their advantage. They negotiate good contracts (in some cases it's just because they negotiate...
1761.78	Hitting some high points	RIPPLE::PETTIGREW_MI		`Thu Feb 20 1992 00:36`	84
	RE: Last several The last string of replies has given me lots to think about. It has been very enjoyable. Here are some points I thought were especially important: 1761.71 (BANKS) > I don't think I've ever seen a sane software requirements definition in the > entire time I've worked at Digital. I do not think this is limited to DIGITAL. I have never in my entire professional experience seen an initial requirements definition that was complete, consistent, and correct. A critical process in software development is the continuous verification, validation, and correction of requirements. 1761.72 (MACDONALD) > A good first step would be for us to admit to ourselves that we have > been avoiding the hard work of developing good requirements and that we > have to stop doing that. It is hard work isn't it! Can anyone point to management styles which truly encourage this sort of work? How can we tell if we are getting good requirements? What should we do if things are slipping away into the fog? It takes more than (in addition to?) hacking great code to do good software development. 1761.73 (CROWTHER) > perhaps we might listen to the "Voice of the Customer" and give them > what they want instead of what we want to give them. That sounds like a very effective style for management and for individual contributors. Are there any good examples of groups who are doing this now? 1761.74 (SUCHARD) > Ever wonder why the 1-2 man shop consistently gets the high quality > product out in 1/4 the time our mega-bodied disasters splatter > themselves in the marketplace? There is no mystery at all in this. Small development teams have fewer levels of people, and thus suffer less from communications problems. Such teams have very short response cycles when presented with new information. Software quality is mostly a matter of how well the developers understand the customer's real needs, and how quickly this understanding can be manifested in a working application. 1761.75 (BANKS) > They shipped the prototype. When you are picking two items from the list of (FAST,GOOD,CHEAP) one of the items always has to be FAST. Of course a profitable software development businesses must consistently deliver all three characteristics. How do they do that? 1761.76 (DAVIS) [Successes of EDS, ANDERSON, etc] EDS does not succeed everywhere and neither does Anderson Consulting. It is very important to understand the limits of successful behaviors before adding them to our own repertoire. EDS has consistently done well in regulated industries (Banking, Insurance), and in Facilities Management contracts for these industries. They are good at government work. Outside of this area their record is quite spotty. Anderson Consulting has done well in a number of different business areas. They always seem to use a top-down sales strategy and a lot of "relationship building" with executives. It works until they hit areas that have significant technical content. Both EDS and ANDERSON make it very easy for the customer to write change orders on their "fixed-price" contracts. They charge ruthlessly for every one of them too.
1761.79	The opportunity is there . . .	CAPNET::CROWTHER	Maxine 276-8226	`Thu Feb 20 1992 08:06`	23
	re .78 Of course there are places where the Voice of the Customer is heard, they are the companies that are making a profit and winning awards like Malcolm Baldrige. Digital suffers from a terrible ego problem - we do it best and we don't need anybody's help. Engineers, software designers, etc are coming up with elegant designs that top the industry BUT they are not what customers want. Harken back to the days of the Rainbow etc. Best computers on the market and nobody bought them - why - because they were the best computers on the market! We not only have to listen to our customers but we have to live with them. The most effective system I ever designed was designed after actually participating in the work the customer did. Watching and even wading in. How many of us have ever asked to do that? And on the other side how many of us leaders have allowed our team to do just that?
1761.80		VIRTUE::MACDONALD		`Thu Feb 20 1992 08:51`	39
	Re: .73 >I come from the IS world many moons agree and while I agree with the >comments about software, I can't help but wonder why we can't figure >out how to solve the problem of the changing spec. Is it because we >don't prototype and the development period is too long? Is it because >we don't ask the right questions? Is it because we make too many >assumptions? There are probably a myriad of reasons for the changing spec, but I believe they are all rolled up into the general truth of not understanding the customer needs well enough. I have seen time and again that we come up with our own ideas of what should be done, start coding, and then at numerous places in the development process come bits and pieces of information about what competitors are doing, what new feature one vocal customer wants, what new capability a marketing group wants because it is needed to support the strategy they are developing, etc. When these things happen, frankly, engineering has no concrete idea of just how important the new request is because not fully understanding what they are doing anyway, there is nothing to compare this new request against. The pressure comes from any number of places to add this new feature; development management says add it; and a new, poorly understood, factor is added to the software with the engineers having no way to know how that is going to affect the result. If we were more disciplined up-front to develop concrete requirements which were clearly tied to customer needs and what problem we were trying to solve, then each time a request came up to make a change we'd be able to make an informed decision having a clear idea of what the result would be of either doing it or not doing it. Simply put, the way we operate now, engineering has no way to quantify the risk/benefit of any proposed change so without any concrete data to back them up, they have no leg to stand on when they're told to "Just do it". It's a vicious circle. Steve
1761.81		CIS1::FULTI		`Thu Feb 20 1992 08:56`	30
	re: .73 >Is it because we >don't prototype and the development period is too long? Is it because >we don't ask the right questions? Is it because we make too many >assumptions? >Instead of blaming users and "them" why don't the folks most affected >do a root cause anaylsis of some sort to try and find the answer? Or >perhaps we might listen to the "Voice of the Customer" and give them >what they want instead of what we want to give them. Well, those of us in application development have the exact same problem. The 'users' pay the freight, and with very few exceptions in my experience they, the users, do not want to pay for 'prototyping' or anything else that is going to cause any sort of delay in getting down to the actual coding. So, we start with an 'idea' of what they want. If we are very, very lucky we get a spec. Most people laugh at the stories of specs being drawn/written up on napkins, etc, etc. But, in reality its not so far from the truth. Another problem I believe is the fact that the users do not know what it is that they are really looking for. Requirements are typically, "We need a foobar application, with a report that looks like this...." this is said as speaker reaches for a napkin. To answer your other question, who has the resources to do any kind of study? I have an application to get out that has an unreasonable delivery date. Right after that, I need to immediately start on the next release. And on and on it goes. Now, my reaction to Six-Sigma... Well, you really don't want to know... - George
1761.82		CIS1::FULTI		`Thu Feb 20 1992 09:05`	14
	re: .75 Boy, and I thought that I was the only one that something like that happens to... The adage is soooooo true: Software development can be Good, Fast, Cheap pick any two How about the user telling you after you have delivered.. "Yeah, thats what I said to do but, its not what I want". I continually ask but, can never get an answer to "Why is there never time to do it right but, always time to do it over"?
1761.83		VIRTUE::MACDONALD		`Thu Feb 20 1992 09:08`	24
	Re: .81 >To answer your other question, who has the resources to do any kind of >study? I have an application to get out that has an unreasonable >delivery date. Right after that, I need to immediately start on the >next release. And on and on it goes. For sure, many people in development are forced to operate this way. The point is that if the company continues to force this way of working on you, WE WILL BE OUT OF BUSINESS in the not too distant future. This way of working evolved during a time when market and business conditions were such that we could get away with it. Those days are over. We have the resources and time to carefully evaluate what customers want, but we are spending them on things that are not benefitting us. If we could stop doing that, you'd have the time and money to figure out what is important first and then just do it. >Now, my reaction to Six-Sigma... Well, you really don't want to know... Have at it. I'd like to hear what you have to say. Steve
1761.84		CIS1::FULTI		`Thu Feb 20 1992 09:42`	13
	re: .83 Yes, we are a BIG part of the problem, but, the users/customers are not without blame. In my case they are forcing this kind of schedule. Probably to their detriment but, they dont realize it and for reasons that I dont want to go into here we are pushing forward. > >Now, my reaction to Six-Sigma... Well, you really don't want to know... > Have at it. I'd like to hear what you have to say. Suffice to say that it requires discipline to be effective and in my experience to date, we lack such discipline.
1761.85	What's wrong?	WHO301::BOWERS	Dave Bowers @WHO	`Thu Feb 20 1992 09:50`	18
	1. An obsession with budgets and dates. How many times are you asked to commit to costs estimates and delivery dates before you've the vaguest idea what you'rte developing? 2. A persistant myth that coding is the "real" work. As a result, we don't research enough, we don't plan and design enough and we don't test enough. 3. A tendency to treat requirements documents like shopping lists. No one in his right mind would ask that the next generation Boeing 747-xxx include a swimming pool and a backhoe, but lots of software has had similar afterthoughts grafted on. Remeber Weinberg's 1st Law: "Plan to throw away the first version. YOU WILL ANYWAY!" -dave
1761.86	Software development is different	STAR::DIPIRRO		`Thu Feb 20 1992 09:51`	20
	That's too simplistic. Things are changing so fast in the industry right now that most people don't really know what they want. So we get very conflicting messages from our customers and a different set of "requirements" from each one. Since the company is so focused on short-term profits and turning things around right now, we're trying to figure out ways to make everyone happy...and the truth is, we can't. What this does is result in even more confusion internally as to where we should be focusing our energy and resources. Consider why we're doing Alpha. Do we have specific requirements from customers? They want better price/performance, open systems, etc. This leaves a lot of flexibility. So as Alpha became more defined, new requirements were (and still are) coming in all the time. Trying to put a stake in the ground is nearly impossible, but you have to do it in order to ship something. You defer things to later releases, and you keep analyzing new requirements. It's an ongoing, iterative process which typifies software development and differentiates it from other disciplines (if I can use that term loosely). In many software development environments, you can't just produce your requirements, write your spec, implement it, ship it, and go back to square one. It just doesn't work that way.
1761.87		VIRTUE::MACDONALD		`Thu Feb 20 1992 09:56`	31
	Re: .84 >Yes, we are a BIG part of the problem, but, the users/customers are not >without blame. In my case they are forcing this kind of schedule. >Probably to their detriment but, they dont realize it and for reasons >that I dont want to go into here we are pushing forward. Yes, customers are not without blame. In fact the TQM philosophy makes it clear that the customer has a responsbility in the process of satisfying them. Unfortunately, it is up to us who want their business to work with them in such a way that they fulfill that responsbility whether they know it or not. I would also agree, that they probably don't know when they themselves are the biggest contributor to their own dissatisfaction, but diplomacy makes it impossible to tell them that directly. I hear what you're saying about the reasons for pushing forward, nuf said. >>>Now, my reaction to Six-Sigma... Well, you really don't want to know... >> Have at it. I'd like to hear what you have to say. >Suffice to say that it requires discipline to be effective and in my >experience to date, we lack such discipline. OK, I can go along with that assessment 100%! Any ideas for how to solve the lack of discipline problem? We're going to have to solve it if we want to stay alive. Steve
1761.88		FIGS::BANKS	Vice President in charge of VMSMail	`Thu Feb 20 1992 10:26`	28
	I really don't see that prototyping adds to the overall development effort. If you can dash off a quick hack you can use it to answer a few questions: 1. Whether or not it's what people really wanted: When they see something tangible, they get a chance to decide whether they need some fine tuning. 2. How you really want to design things: The best way to figure out the "right" way to implement something is to try the wrong way first. Fortunately, the "wrong" way tends to be the first one you pick. 3. How long it's really going to take you: Having done it once, you get a better realistic feel This is all part of the design process, or maybe even the functional spec process, and is in no way related to the actual development process, other than to give you a handle on what the development process will be like. Now, I'm sure you're still wondering how I deluded myself into thinking that this doesn't add to the overall schedule. I don't think it does. It seems obvious, but if you write software with no bugs, even if it takes you longer to write, you'll have a net time savings when you don't waste all that time fixing the bugs later on. By the same token, if you start with a good design and overall structure, you won't waste a lot of time later on, trying to hack the bad design into shape, redesign and reimplement subcomponents, etc. In other words, get it right on the first try, and you won't waste time fixing the wrong stuff. And, you'll end up with a much more maintainable product.
1761.89		VIRTUE::MACDONALD		`Thu Feb 20 1992 10:50`	31
	Re: .86 > That's too simplistic. What is too simplistic? > Software development is different. Baloney! I agree with your descpription of the software development environment, but it is not unique and it is that way more because we refuse to change than for anything inherent in software development. Every market is changing rapidly, not just software. I'd bet that if you edited .86 replacing software with Walkman the engineers building them would say you're right on the money, but I'd also bet that they been allowed to develop a process for dealing with that problem. The reason I react so strongly to this is that I often hear this as the reason why Six Sigma, TQM, Continuous Improvement, etc. won't work in software (or services or shipping or... take your pick). Are we talking NIH perhaps? Frankly, it was rapid change eroding their competitiveness nearly overnight that sent manufacturing to Continuous Improvement for help. Other industries are solving this problem. Telling ourselves we are different is just delaying facing the truth: WE HAVE GOT TO CHANGE. Steve
1761.90	My QFD textbook sits at home collecting dust...	BIGJOE::DMCLURE	Just say Notification Services	`Thu Feb 20 1992 11:21`	42
	re: Six-Sigma, etc. Based on the definition of Six-Sigma slogan that I have heard (i.e. some extremely low percentage of defects per units manufactured), I tend to think Six-Sigma has less to do with meeting customer requirements and more to do with the quality control of a given product. In this sense, Six-Sigma alone could successfully produce extremely high quality Edsels that nobody might want. It is only when you harness QFD (Quality Factors Development - not to be confused with the "ivory tower" phase review process) to your quality controls that you have a shot at achieving the goal of customer satisfaction. In my opinion, I see the problem as being a lack of management expertise in QFD. As a Software Engineer, I was trained in QFD, but due to the traditional business struture and practices in this fledgling software industry, I am rarely able to utilize many of these techniques. Unless and until product management (who is ultimately "in charge" of the development process) becomes knowledgeable of QFD to the point where they can actually develop a product utilizing QFD, then customers will continue to be only quasi-satisfied (if even that) with the end product. The reason is because the formation of customer requirements and associated quality factors for a given development project is something which typically occurs long before engineering "resources" are ever even interviewed to work on a given project (much less do they have a chance to come up to speed on the issues and the overall environment until the project is well underway). In other words, the only people who are sufficiently trained in QFD are not even typically included in the initial (and consequently the most important) QFD phases of the project! Is it any wonder why QFD is not utilized? QFD is not something you can slap on at the last minute. QFD is the process which must drive the development of the product from day #1. To fix this situation, we either need to stop treating engineers like migrant workers and give them more control over the early phases of a project's development, or we need to train our managers in QFD and let them manage the QFD process. Somehow, the people who are involved in the early phases of a project need to be knowledgeable of the QFD process so that the customer's definition of a quality product doesn't continue to fall through the cracks. -davo
1761.91		MIZZOU::SHERMAN	ECADSR::Sherman DTN 223-3326	`Thu Feb 20 1992 11:24`	28
	re: .79 I disagree just a tad about why the Rainbow failed. When it came out I was a student at the University of Missouri at Columbia. We had a lab full of Digital equipment. It had a PDP-8, a bunch of LSI-11s and a Rainbow. The Rainbow looked cool. It had a program on it that would draw a colorful map of the United States. We all wanted to do our projects on it instead of the PDP or the LSI-11s. But, none of us did anything on it. Why? Because we could get cards for free to program up the PDP. We could get cheap floppy disks for the LSI-11s. But, the Rainbow required pre-formatted floppies that the local bookstore was charging about $10 for each. A cough, and laugh and a sigh and I went back to work on an LSI-11 after I found out about that. As to some of the other comments about customers and software my only experience concerns software development internally, but a lot of the same details apply. What I've found is that customers can easily tell you what they want today. But, by they time you come out with it their needs change. So, you have to find out what they want today and then guess about what they will want when you generate your first version. That means you have to do R&D if you want a successful software product. That's how it is that you guess what they'll want. Otherwise, you're stuck with "Digital will have what you wanted yesterday, tomorrow" rather than "Digital has (what you want today) now." Steve
1761.92	Let's hear it for behavior modification	TOOK::SCHUCHARD	i got virtual connections...	`Thu Feb 20 1992 11:41`	17
	re: .paul - ya, sorry, i lost my head. re: .pettengill(mangled?) - is it not amazing that a simple truth is persistently ignored? No, we've become a company where you build to keep your boss happy, and if the customer as a side benefit prospers, great! I once tried to object writing a component spec for something i knew didn't work. Lost my job, and before things got done, DEC lost about $30-50 million. MY mistake was my motivation came from being firehosed by customers. I needed a mind-set adjustment, but it took longer(several years) than required. I hear lots of talk about getting priorities(customer first) straight, but i'll think hard before i put the customer before my manager again. bob
1761.93	It's called "cover your a.."	GOLF::WILSON		`Thu Feb 20 1992 12:54`	12
	RE: Note 1761.92 >> we've become a company where you build to keep your boss happy, and >> if the customer as a side benefit prospers, great! >> I hear lots of talk about getting priorities(customer first) straight, >> but i'll think hard before i put the customer before my manager again. Bingo, you've hit the nail right on the head! And in turn, as our number one priority is to please our managers, (IMO) too much of the company's energy is spent on pleasing Wall St. and not the customer. Rick
1761.94	Here's what I'm trying...	MAY21::PSMITH	Peter H. Smith,MLO5-5/E71,223-4663,ESB	`Thu Feb 20 1992 13:13`	37
	Re: .92 and .93 I'm still learning in this area. I'm encouraged to have moved to a group which is currently circulating a set of "values/mission" slides, developed at the VP/staff level, for feedback. Those slides reflect a lot of values which we have feared that Digital is losing. In the past year, I have started to try the following when I disagree, whether it's with my direct management or someone I need to work with. 1. First, make it clear, politely, that I'm disagreeing, as opposed to "discussing", or "suggesting alternatives." 2. Clearly state the reasoning behind my disagreement, and get the party I am disagreeing with to _repeat_back_to_me_ my reasoning. Without this step, it's easy to be brushed off. 3. If the area of disagreement is outside of my area of authority, defer to the appropriate decision maker. This sometimes means saying, "tell my manager to tell me to do it," and sometimes it means saying, "you're my manager/leader, and although I have voiced my concerns, I will defer to your final decision." I don't like confrontation, which makes steps 1 and 2 hard, and I don't swallow my ego easily when I feel that a decision is "arbitrary" and my position is "technically superior", yet the other parties see it differently. But I do find that steps 1, 2, and 3, followed consistently, have led to better working relationships. Also, I have found that, once I have gone through the loop a few times with someone, steps 1 and 2 are less painful because they know that when it comes to step 3, I'll take "no" or "do it" and act on it. I realize that some managers won't let you do steps 1, 2, and 3, but there are places in the company where they work. I'm glad to be there. If you're in a tight spot now, .92, don't give up. Keep communicating, and if it isn't working, keep your job while you work on moving to a situation where you can be more effective...
1761.95	Quality is free - let's use it . . .	CAPNET::CROWTHER	Maxine 276-8226	`Thu Feb 20 1992 14:02`	19
	The message that I am hearing is two-fold: 1) There are a lot of excuses (valid or not) for allowing bad practices to continue. No blame to anyone who finds them- selves in an untenable situation - I've been there too. 2) A Quality environment is a long way away. Each of you who isolates one tool and calls it Quality is wrong. Quality is not 6 sigma or QFD or JITQC. Quality is an environment that points all work toward the customers and uses a whole set of tools to perform the work. Quality = improvements for customer made by employees. The tool set we use is only as good as the input and the input in the case of software development is flawed for one reason or another. No matter what tool you use you will not solve the problem without the customer. So the question is - how do we solve the problem - how do we get a process that will allow us to do our jobs properly?
1761.96		SQM::MACDONALD		`Thu Feb 20 1992 14:48`	32
	Re: .90 > Based on the definition of Six-Sigma slogan that I have heard >(i.e. some extremely low percentage of defects per units manufactured), >I tend to think Six-Sigma has less to do with meeting customer >requirements and more to do with the quality control of a given product. >In this sense, Six-Sigma alone could successfully produce extremely high >quality Edsels that nobody might want. It is only when you harness QFD >(Quality Factors Development - not to be confused with the "ivory tower" >phase review process) to your quality controls that you have a shot at >achieving the goal of customer satisfaction. The part about defects per units manufactured etc. is only part of the Six Sigma program and that part is at the back end. It is, indeed, about quality control, but quality control to ensure that the process is producing what at the front end you determined customers wanted. At the front end of Six Sigma is the admonition to be darned sure that you know what customers want to buy and that you use reliable methods and tools to ensure that that is what you deliver. Six Sigma strongly encourages the use of QFD as a method of helping you to know what customers want to buy. Re: .95 Yes, yes and yes again! Six Sigma, QFD, TQM, whatever are just tools. The point is quality = customer satisfaction. It doesn't matter which tool you use to get it as long as you get it. Steve
1761.97	A Quality Portfolio should also exist for each customer	BIGJOE::DMCLURE	Just say Notification Services	`Thu Feb 20 1992 16:27`	38
	re: .95, I buy most of what you said, but as to your question: > So the question is - how do we solve the problem - how do we get a > process that will allow us to do our jobs properly? I tried (albeit perhaps somewhat unsuccessfully) to supply an suggested approach to solving this issue in reply .90. To summarize, I think the people with the power to lead a product to market are the ones who need to be not only trained in <insert favorite quality slogan here> methods, but they need to be able to insure that the products under development utilize these methods in the development process as well. Whether these empowered people are account representatives, product managers, project leaders, engineering consultants, grunts, or what have you is besides the point. What matters is that people who are well trained in <insert favorite quality slogan here> are involved in the entire quality factors development process from the beginning of the project, such that the project is based on a set of requirements which can then be adhered to throughout the life cycle of the product. Obviously changes will be made to the original quality requirements over time, but the important thing is to maintain some sort of consistent quality portfolio for the product as it changes. Upon joining an engineering project which is alread underway (as is typically the case for engineers working on long-range product development projects), a given engineer should be able to ask the question "so, where are the quality requirements documents for this particular product?" and be pointed to an up-to-date set of quality requirements (which are preferably on-line for easy updating). As it is now, when you work on a given project, you are expected to simply "do a quality job" - which translates to somehow uncovering the quality requirements (as defined by the customer) through some sort of ESP. I suppose this is why engineers are refered to as "gurus"? ;^) -davo
1761.99	What's the first step . . .	CAPNET::CROWTHER	Maxine 276-8226	`Fri Feb 21 1992 08:07`	3
	re .97 I agree - now how do we get there????????
1761.100	First understanding the problem	TOOK::SCHUCHARD	i got virtual connections...	`Fri Feb 21 1992 09:04`	51
	Actually, here in NaC things have become much better. After not listening to dissenting engineers and customers over 5 years, the reception to our new product set has forced the issue. Too many people can't seem to handle product criticism, yet if you are ever going to succeed, you have to listen very carefully to what customers - especially the ones who hate what you've done, have to say. We went thru a few years where bad news was seen as not team playing - emphasize the positive or die. Nothing positive comes out of this. People start prospering on the wrong metric's and eventually the marketplace will make either get well in a hurry or die. We should ALWAYS be listening for criticism, understanding what it means, and how it can be used to make things better. If you approach it from that point of view, it does become a rewarding exersise, both personally and (for the company) financially. As far as management goes, the metrics have to be right. Taking management behavior(generally) in a personal manner is counter-productive. People generally behave(except for me;-)) in a way they perceive will bring success. If success is defined as maintaining the stovepipe, or short-term success, whatever, you will find most managers following that model - they have mortgages and families also. When we create large organizational webs - often done for what seemed at the time like good reasons, we create more conflicting metrics. We may all have the goal to make our customers happy, but depending on what function you perform, what's required is differnet and frequently conflict. The trick is finding the right trade-offs, and it is not easy to do. Especially when budget amounts represent power and prestige. The only real way to achieve this is by ensuring that rewards follow the appropriate behavior - company culture is a BIG aspect of this. I see where I'm working that the culture IS changing for the better, and we have 2 new VP's who appear to take great value in that. That certainly makes me feel a whole lot better than I have for much of the last 5 years. All is not doom and gloom - there are business opportunities out there if we are smart enough and open enough to find them. The real challenge comes when the good times roll around again. Most bad stuff happens when the money is rolling in and we can "afford" to let our priorities gets screwed up. Obviously, we cannot "afford" these behaviors. It leads to a lot of personel pain, as we have witnessed. bob
1761.101		SQM::MACDONALD		`Fri Feb 21 1992 09:12`	15
	Re: .100 >The real challenge comes when the good times roll around again. Most >bad stuff happens when the money is rolling in and we can "afford" >to let our priorities gets screwed up. Obviously, we cannot "afford" >these behaviors. It leads to a lot of personel pain, as we have >witnessed. You've got this one right. When we were fat and happy, the revenue stream just obscured disaster waiting to happen and as soon as the revenue stream slowed down it did. Steve
1761.102	first, just let it be known and accessible	LGP30::FLEISCHER	without vision the people perish (381-0899 ZKO3-2/T63)	`Fri Feb 21 1992 09:29`	31
	re Note 1761.65 by STAR::ABBASI: > we should have a company wide software libraries, > that every one can access and pull from it the right software components, > it should be catalogued and well specified, and portable. nasser, I agree with you, and I essentially agree with .68 that there already is a lot of informal code- and idea-reuse. Conventional software techniques almost always require some re-work in the process of re-using code; object-oriented techniques offer the promise of less re-work for re-use. While it is clear that it would be best if software was "catalogued and well specified, and portable", I suspect that a lot of code would either be re-used or at least imitated if it were easier to access the code of other projects. We live in an environment in which it is considered a potential danger if persons -- even within our own company -- can get access to our code and documents in general. Of course, there are exceptions: some documents, but very little source code, is written specifically for a wide non-project-specific distribution. But those are really the exceptions. I have never been convinced that general within-company restrictions on access are wise. Bob
1761.103	Solution: A Customer Quality Requirements Database (CQRD)	BIGJOE::DMCLURE	Just say Notification Services	`Fri Feb 21 1992 12:09`	40
	re: .99, > -< What's the first step . . . >- > I agree - now how do we get there???????? Well, we could always storm the palace! ;^) Ok, we are agreed that quality factors development methods need to be employed early on in the design and development phases of a product so as to insure that customer requirements are being met by given products. We are also agreed that a quality requirements "portfolio" be maintained for each customer (or at least each industry). These portfolios would need to contain quality requirements of customers in some sort of standard format so that they could be easily, quickly, and accurately mapped to quality factors for any given product under development. I suggest some sort of database be developed to store this data. A quick perusal of the latest easynotes.lis file reveals various industry-specific notesfiles for such industries as the banking industry (YUPPY::RETAIL_BANKING), the pharmaceutical industry (PHDVAX::PHARM_INDUSTRY), etc., etc. These notesfiles could (and may already) serve as repositories for general hints and customer requirements. This data could be refined and used to initially populate the proposed customer quality requirements database (CQRD). Meanwhile, two user interfaces would need to be developed to access the CQRD, one for DEC reps who collect customer requirements, and another for the product developers to translate these requirements to quality factors and meet these needs with actual products. The data flow design for such a system might look like this: ______ +-------------+ +--------------+ /(CQRD)\ +---------------+ +-------+ \| [potential] \| \| DEC \| /Customer\ \| DEC Product \| \| \| \| customers \|-->\| Customer Reps\|-->( Quality )-->\| Developers \|->\|Product\| +-------------+ +--------------+ \Reqs. db/ +---------------+ +-------+ ^ \______/ \| \| \| +--------------------------------------------------------------------+ -davo
1761.104	QFD in Digital...	CALS::DIMANCESCO		`Fri Feb 21 1992 16:17`	9
	Things aren't all that bad. I think Dave Stone has directed TNSG to make heavy use of QFD in new projects. My management has encouraged me to get involved in at least two QFD's. The QFD notes file (METOO::QFD) is full of Digital QFD experiences. d
1761.105		SQM::MACDONALD		`Mon Feb 24 1992 09:29`	12
	Re: .104 >Things aren't all that bad. I think Dave Stone has directed TNSG >to make heavy use of QFD in new projects. David Stone will announce probably within a month or so a TNSG policy that QFD must be used in development projects or there must be an approved plan that includes an appropriate alternative. Steve
1761.106		REGENT::POWERS		`Mon Feb 24 1992 09:39`	47
	> <<< Note 1761.68 by RIPPLE::PETTIGREW_MI >>> > Hardware manufacturing is different from software development because > manufacturing is all about the consistent replication of a single > well-specified product. WRONG!!!!! Manufacturing is about the consistent application of a process to generate the instance of a product you care about right now, from the non-optionable widget stampers to every-copy-different customizable production line. There's a process in place in an auto retailing chain to capture your specs on the showroom floor, return those specs to the factory, and get you the right model, color, options package, and such at a specifiable time. > Software development is all about creating > a product from ill-defined requirements and building (or growing) one > unit of that product. BULL!!!!! That MIGHT be an accurate description of PROGRAMMING (or HACKING, to put it more bluntly), but software DEVELOPMENT is a process of capturing and abstracting INTENT and translating that into specifiable elements. Those ELEMENTS are what can be re-used the same way a fender stamping machine in an auto plant can be re-outfitted with new dies to produce different fenders for new models. Think "Run Time Library" on a larger, more abstract scale. Think Macintosh with its more consistent REUSABLE human interface components. > Software development is similar to hardware (prototype) development. That's because too many people still get away with calling software development a "craft" or an "art." Software ENGINEERING is too little practiced, both here and in the industry at large. Software ENGINEERING is different from computer science, both of which are different from programming. Yes, software gets to skip the drudgery of what hardware has to go through in manufacturing. The business pressures to run off multiple copies of the latest baselevel and ship them to customers need to be understood. If we had Star Trek-style matter replicators, hardware would be just as bad. But software is not inherently different. Repeat that: software is not inherently different. It needs to be DESIGNED before it can be IMPLEMENTED. - tom powers]
1761.107	Do you really want re-usable? How about re-used bubble gum?	VAULT::CRAMER		`Mon Feb 24 1992 10:30`	28
	re: .106 et. al. Oh if only it were so. >Think Macintosh with its more consistent REUSABLE human interface components. Now think user who doesn't want the a consistent, reusable human interface and instead demands one in which every idiosyncracy imagineable is supported. E.G. Cntrl Z means go to the next mandatory field. And BTW, these are the people with the money who fund the projects. Re-usability, at the application level, requires some level of standardization in form and function. Imagine an auto where the customer could specify not only color, but size, shape and style of seats , number of wheels, gauge size, style and placement, etc. not from a list of two, but from the virtually unlimited possibilites that could be imagined.(I don't care what you say, I want the speedometer in the drivers door!) Unfortunately, the first application to be built with re-usable components incurs all the costs (it is usually cheaper to do custom knockoffs, or at least no more expensive) so the user wants all the bells and whistles. The second application is where the savings happen. But also where the compromizes have to happen. If we want to do re-usable, we have to change the funding model. Alan
1761.108	Development differs from Manufacturing	RIPPLE::PETTIGREW_MI		`Mon Feb 24 1992 12:28`	49
	RE:106 (POWERS) The inappropriate use of a successful manufacturing principle in a development environment will result in a failed development activity. Development is quite a different activity from Manufacturing. The key difference is the plastic nature of the Functional Requirements in Development. Manufacturing processes deal with fixed specifications and very limited degrees of freedom (optional features). Flexible manufacturing can deal with many degrees of freedom, but every manifested requirement will have an exact and unambiguous specification. Development processes deal with ambiguous requirements which change as a result of the processes, and also change over time. Analytic methods will affect requirements definition. Design technique can modify requirements. Coding and testing may uncover emergent requirements. Implementation is certain to change the end-user perception of requirements. Time changes everything. Development processes have an iterative nature, and may overlap in ways that are often overlooked in simplistic methodologies. Analysis and Design commonly overlap, moreover, the available design methods often constrain the perception of functional requirements and the direction of analysis. Requirements may change at a rate that is faster than the development processes - an unstable situation that leads to project failure. The general answer is not to "freeze" the requirements, but to speed up the iterations and cycle times of each development process. .."It needs to be designed before it can be implemented".. This is a statement of faith, which is easily contradicted by observation. There are many successful applications and systems which were never designed in any overall fashion. Look around, and you will find other applications that are being used in ways that their original designers did not anticipate. There seems to be a minimum core to a system, which must be designed and built to well-understood functional requirements. Beyond the core there may be a much larger shell, of astonishing complexity and functionality, that "just grows" in response to demands from the end-users. None of that growth can be planned or controlled by current management technique, though it can be fostered or influenced in many ways. Beyond the shell, there are poorly-understood limits to the growth of all systems.
1761.109	Amen	VAULT::CRAMER		`Mon Feb 24 1992 12:43`	22
	re: .108 How right you are. The problem in designing application software comes down to a definition of "levels of abstraction". There must be a well designed and well understood, core that supports a decreasingly well understood set of requirements. The users can not specify everything. They don't know all the answers. Hell, they don't even know all the questions. It is the job of the systems designer to elicit the unchanging core, and then to abstract it to the point where more and more flexibility can be layered on top with out the structure crumbling. This requires two things: 1) A user that understands the need to trade off between getting every whim pandered to, and quickly getting a flexible and powerful system; and 2) a designer who is capable of working at the various levels of abstraction necessary to design for the unknown and the unknowable. Alan
1761.110		CALS::THACKERAY		`Mon Feb 24 1992 17:05`	39
	Re: Last few, regarding difference between developing software and hardware. I agree with POWERS; fundamentally, developing software should not be different from developing hardware. Hardware products are designed to meet customer benefit requirements through function. The physical implementation of the hardware meets the functional requirements, and the production processes should be designed to optimally meet the various goals of customization, economy of scale, etc. Similarly with software, if GOOD development process is used. I agree that, when "hacking", software development looks very different, but when software is designed properly, it goes very much like hardware. What do I mean by "designed properly"? I mean that the surprises are eliminated by appropriate requirements analysis and prototyping to test that the requirement assumptions are correct. Same in hardware, you make prototypes (either in simulations or breadboards. In automotive, a "mule" is constructed). When this is done effectively, software development becomes a joy to behold, as opposed to our sadly more usual "unfolding requirements and changes" syndrome. Incidentally, the key methodology to ensure good process in developing software is to use QFD. I have a case study which shows the following: 100-to-1 productivity improvement ratios over existing similar projects. 98% compliance to original requirements assumptions 100% compliance to prototype-tested requirements Profitable product at first revenue shipment. Ray
1761.111		CALS::THACKERAY		`Mon Feb 24 1992 17:12`	23
	Re .109: >This requires....a designer who is capable of working at the various >levels of abstraction necessary to design for the unknown and the >unknowable Utter rubbish. This is the kind of thinking that keeps software development in the dark ages and "architects" thinking that they are some kind of latter-day Merlin. If, after any kind of modern requirements analysis (like QFD and Contextual Inquiry), you believe you are developing software that is the "unknown for the unknowable", you should not be working in product development. Maybe you should sell your services to a 1-900 astrological advisory service. If I was an investor in a project in which the designers have this kind of attitude, I would pull my dollars out instantly and buy government bonds. Ray
1761.112	At the edge of the Known...	RIPPLE::PETTIGREW_MI		`Mon Feb 24 1992 19:09`	68
	RE: 1761.110, 111 (THACKERY) > I agree with POWERS; fundamentally, developing software should not be > different from developing hardware. POWERS has asserted that software development is very similar to hardware manufacturing, and that lessons from manufacturing can be applied directly to software development. I do not believe either of this positions are consistent with any careful study of the software development business. Developing software is very similar in many ways to developing hardware. Developing software is very different from manufacturing hardware. Lessons learned in manufacturing do not have the same application in development. > What do I mean by "designed properly"? > > I mean that the surprises are eliminated by appropriate requirements > analysis and prototyping to test that the requirement assumptions are > correct. Same in hardware, you make prototypes (either in simulations > or breadboards. In automotive, a "mule" is constructed). > > Incidentally, the key methodology to ensure good process in developing > software is to use QFD.... And I can cite nine different applications, each using a different methodology, each one quite successful. The only common thread in all of them was that the development process was relatively short (less than twelve months), and the subsequent release cycle was also short. The cycle time for development processes must be faster than the underlying rates of change in functional requirements, else all methodologies fail. QFD is certainly a good method for defining consistent functional requirements, and relating them to a design. It is not the only way to develop a product, however, and it does not guarentee complete or valid requirements. Let's take a look at the current conversations about Lotus NOTES and how it was created. The success of MS-DOS conclusively refutes the last 20 years of Software Engineering methodology. The percieved triumph of UNIX does not even fit into a discussion of methodology. > If, after any kind of modern requirements analysis (like QFD and > Contextual Inquiry), you believe you are developing software that is > the "unknown for the unknowable", you should not be working in product > development. > > Maybe you should sell your services to a 1-900 astrological advisory > service. These remarks are uncalled for. A good methodology will improve the consistency of functional requirements, but it cannot guarentee completness or validity of those requirements. There is always an element of the "unknown and unknowable" in the needs of a customer. Methodology and management are needed to expand the boundaries of the known and knowable. Major product successes are at the edges where the rules don't seem to work so predictably.
1761.113	Rubbish? Hardly.	VAULT::CRAMER		`Tue Feb 25 1992 08:41`	24
	It's ashame that you are so out of touch with the real world of application development. Or is it software design? Here's a little test for you: Design software that will allow you to track all contracts that DEC will write for services over the next 5 years. This includes any licensing, 3rd party relationships of any kind, delivery requirements, pricing (with adjustments) and full financial auditability, security and integrity among others. What you mean you don't know what services we'll be selling in 5 years? What, your users don't know what services they'll be selling or who will be providing them? You mean you're supposed to write a system that will handle the unknown and the unkowable? RUBBISH!!!!! To design this piece of software, it is required that the designer abstract data and process to a point where it can be applied to contigencies that are unknown and unkowable without skipping a beat. This level of abstraction requires someone who is trained in the techniques of the craft. Very few "users" have the requisite skill set. Alan
1761.114		REGENT::POWERS		`Tue Feb 25 1992 08:50`	34
	> <<< Note 1761.112 by RIPPLE::PETTIGREW_MI >>> > POWERS has asserted that software development is very similar to > hardware manufacturing, and that lessons from manufacturing can > be applied directly to software development. You take this stand from my introductory remarks in .106, which are a reflection of your .68. My intent, as Ray has noted, was to accent the similarity between hardware and software development (engineering), both of which are different from hardware manufacturing in starting and ending points, but which could benefit from an analysis of what having a PROCESS provides for manufacturing. > Major product successes are at the edges > where the rules don't seem to work so predictably. But you can't build your business on the ability to make "Major product successes" your entire business strategy. The haberdasher doesn't stay in business because of the number of customers who come in to replace their entire wardrobe of business suits - he stays in business selling shirts, socks, slacks, the occasional top coat, a suit here and there to lots and lots of customers. You only get so many Notes, RdBs, TP systems, and so on per decade. You get lots of upgrades to these, and to the myriad of smaller, less glamorous products (compiler back ends, or accounting package front ends, for example). THOSE are the bread and butter products that need to have a DESIGNED and ENGINEERED base on which to build even "unknown and unknowable" capabilities reliably and predictably. (And the extensions have to play by the design rules and be designed and engineered into the base product to maintain extensibility, or you have to know why not. That's Process, again.) - tom powers]
1761.115		CALS::THACKERAY		`Tue Feb 25 1992 10:36`	17
	Re: .112 PETTIGREW_MI > A good methodology will improve the consistency of functional > requirements, but it cannot guarentee completness or validity of those > requirements. There is always an element of the "unknown and > unknowable" in the needs of a customer. Nothing's ever guaranteed. But a good product development process can eliminate the surprises. In this case, the unknowns become knowns when an early prototype is used, as a part of the requirements analysis. Therefore, they are not unknowns any more. This is the crux of my argument; that the initial assumptions need to be tested during the early Analysis and Planning of a project, before detail design takes place. Unfortunately, all too often in Digital, the first time a customer sees the product is during Phase 4. Ray
1761.116	The real world?	CALS::THACKERAY		`Tue Feb 25 1992 11:19`	48
	Re: .113 by VAULT::CRAMER > It's ashame that you are so out of touch with the real world of > application development. In the last couple of years, I've co-authored two papers on the topic, which have both been reprinted, internationally. Also, I've been on multiple projects, one is a unique point-of-sale system which has 8 microprocessors and over 1.2 megabytes of object code (which is now entering the market). This product has absolutely no comparison in the market, a totally new concept. Another project is a 20 megabyte hyperinformation, multimedia system, which is due to ship this Friday. I have, during this time, facilitated a new project for a multi-vendor, industry initiative Workflow Management system, done software quality review and setting up next version for a Refinery's Document Management system, and a few other appliactions. Also, I am on the Editorial Board of the U.S. Concurrent Engineering Journal. Prior to that, in England I was Managing Director of a company that produced a CAD/CAM system, and consultant to the British Department of Trade and Industry, helping to modernize small to medium-sized companies in their new product development. After that, I was one of Digital's earliest CAD/CAM consultants in the field (the precursor to the DCC's), in Canada. Am I out of touch with the "real world of application development"? Frankly, I do not believe so. My opinion that software development needs more discipline has been formed over a long time and after having seen and demonstrated better ways. Specifically, I've observed too many of our developers and architects wrapping themselves in veils of mystique, insisting that the world is full of unknowns and unknowables, that they are the seers and custodians of inner wisdom in realms of intangibles. What we really need is more people who can cut through this and turn gossamer into identified characteristics, the output of which, although it may be a large number of alternatives and tradeoffs, can be communicated, understood and turned into products. This takes engineers, not artists. So, my good man, 'tis not I who am out of touch with the "real world of application development", 'tis thee. Ray
1761.117	Thank you for a clarfication	RIPPLE::PETTIGREW_MI		`Tue Feb 25 1992 12:07`	16
	Re:114 (POWERS) "POWERS has asserted"... It seems I have misunderstood part of your basic thesis. Thank you for the clarification. We both seem to believe that software development is broadly similar to hardware development. I take issue with the suggestion that lessons from manufacturing can be directly applied to development. In particular, the processes of development have radically different purposes than the processes of manufacturing. It's important to understand the limits of any sucessful behavior.
1761.118	Am I impressed.?	VAULT::CRAMER		`Tue Feb 25 1992 12:43`	53
	re: .116 You sure sound like you're trying to present yourself as some omniscent guru, oh great and wonderful wizard. Now come down off your high horse and try and see that we are in violent agreement on the major point. > Specifically, I've observed too many of our developers and architects > wrapping themselves in veils of mystique, insisting that the world is > full of unknowns and unknowables, that they are the seers and > custodians of inner wisdom in realms of intangibles. > What we really need is more people who can cut through this and turn > gossamer into identified characteristics, the output of which, although > it may be a large number of alternatives and tradeoffs, can be > communicated, understood and turned into products. > This takes engineers, not artists. Now, can you tell me how this is different than my statement that designers need to be trained in the techniques of their craft? Your replies built a very credible straw man which you then proceeded to torch. Unfortunately you did not consider what I had said. My entire premise was that there is in application design a much larger degree of uncertainty in requirements then there is in hardware manufacturing. This premise led me to the statements that to deal with these uncertainties, which I deemed "unknown and unknowable", that it was necessary for systems designers to have special skills. Do you claim that engineers do not need special skills? For the purposes of this discussion your term, engineer, and mine, system designer, are synonomous; a distinction without a difference. To whit, what is the difference between your: "...cut through this and turn gossamer into identified characteristics..." and my: "It is the job of the systems designer to elicit the unchanging core, and then to abstract it to the point where more and more flexibility can be layered on top with out the structure crumbling." Did you think I was proposing that this abstraction take place on a moonless night via the use of chicken entrails? If so, you were wrong. Now, let's kiss and makeup. We seem to agree that the key to better software is a development process that puts much more weight on proper requirements definition and design than is common today, okay?
1761.119	OK.	CALS::THACKERAY		`Tue Feb 25 1992 15:11`	1

1761.120	RE: .119 Thank you. Now... take my users.......please!	VAULT::CRAMER		`Tue Feb 25 1992 15:30`	0
1761.121	Look! Don't Just Listen....	PIPPER::DOANE		`Tue Feb 25 1992 18:39`	97
	This seems a good, relaxed time in the conversation to add my two cents. I'm delighted with the vigor of this discussion of how to set direction and how to insure it is going to be aligned with what customers will be satisfied with, both now and in the future, both the ones we know about and the customers (and the uses) that havn't yet turned up. What I see missing, is what I'd like to say is the Generating Principle of most of the TQM methods that I'm aware of. Managing by eye. See, the main barrier to knowing what customers need may be that the customers are "skilled" by which I mean, they are wired. They are robotic, on-automatic, habitual. What they do as professionals, as skilled practitioners, is largely fluid, graceful, "second-nature" parallel processing by pattern-recognizers and pattern-generators that they have been biologically altered to possess as part of who they are. Consider how we each learned to "know how" to ride a bike. I ask the audiences I address whether they know how. They assent. Then I ask them to tell me the Requirements to turn 90 degrees left. Rarely can anyone tell me the key steps. They do tell me a lot of stuff, most of it true and a lot of it even useful. But they do not now and have never understood bicycle physics--and the point I make to them is, they didn't have to "know" consciously to "know how because "knowing how" (that is, being skilled) is wired in! At a young age, before there would have been any conversation about physics, they got on a bike, got into motion, wobbled around, and became biologically altered. Of course, I never have a bike in the room when I do this. We do it out-of-context: they are asked to reminsice rather than see what they do as they do it. Since they can't see themselves (or anyone else) ride through a left turn, they can't catch the robotic skilled ability in the act. Whatever they "voice" isn't really worth listening to sometimes; their "requirements" are journalistic observations like "I lean left" or "I shift my weight" with no access to why such a lean or shift is initiated or cancelled--no access to the root cause. So what I've heard missing in your recent conversation on this topic is an awareness that the human beings who will use our software (hardware too, to the extent that humans and not software actually use it) must be observed in action before a conversation for "requirements" will be grounded in the customer's biological reality--her wired-in skill. That's why before using QFD, it is so vital to have the developers go out and hang out with customers where they work and while they work. Contextual Inquiry can involve more elements than I'm covering here, if you want to be really good at it (I hope that you do.) There's a 1-day workshop that Sandy Jones and others teach, to develop that ability. But the most basic essential is the one I'm offering here: you've got to see what is going on. It isn't enough to just ask customers to language at you without seeing what they really can do with that wonderful set of pattern-recognizers and pattern-generators that their life-experiences have had them wired for. I also want to append a little more general comment about managing by eye (TQM methods) and managing by ear (language, numbers.) The ear is a serial channel. Language is a series of names--verbs name actions, prepositions and conjunctions name relationships, etc etc. What's always missing in anything that has been languaged is: shape. You can't language shape, although you can name the pieces of a shape and the aspects of a shape. If the shape is simple, that'll work. If I speak "pentagon" some of you will see the shape of the Defence Department viewed from 30,000 feet and some will see an abstracted regular polygon and one person told me they saw a 5-sided British coin. For such simple ambiguities, a little more languaging will dis-ambiguate quite rapidly. For more complex networks of inter-relationships however, working over the bill-of-materials until the assembly-drawing is duplicated in the two minds' eyes is time consuming and may never converge at all. Then instead of just languaging (which names the bill of materials piece by piece) you have to slow down enough to use that ultimate low-data-rate IO device, the human hand, and draw a diagram or sketch or matrix etc. Having paid that price, the team can then use their eye to see the shape directly. The optic nerve is the Japanese secret weapon. (Or really, the pattern-recognition equipment behind the optic nerve.) The eye is what puts "Total" in Quality Management; the eye can see totalities, while the ear can never hear totalities but only the names of the pieces. So the next time you're discussing "requirements" (I wish we could call them "values" and acknowledge that we're going to trade them off!) please consider how well out-of-context bike riders can speak their skilled behaviors. The can't. Neither can customers, until you catch them in their skilled act. You have to be there, before designing! Russ PS I'd also like to put in a good word for rapid prototyping. Ray makes a really good argument about this--especially when the software will alter the work environment, perhaps making some existing skilled work-arounds unnecessary but also maybe requiring some never-before-required behaviors. You can't catch 'em in the act until they have an appropriate environment in which to act....
1761.122	It all gets back to being a team . . .	CAPNET::CROWTHER	Maxine 276-8226	`Wed Feb 26 1992 08:04`	22
	If I might be so bold as to try to summarize the last n notes, are we all in violent agreement that what we need to be better software developers is more training?? And if so more training in what? I tend to concur with Russ that what we need more training in is BEING the customer. It really is possible to design systems that deal in generalities if you can postulate what some of the conditions might be. The only way that can happen is if you understand the customer's work at least as well as they do. I have had the pleasure over the last 2 years to be working with a software developer who sits right next to me and understands my work almost better than I do. She has developed a system that can change as we change because the kinds of conversations we have deal in what might be not what is. This allows her to anticipate. And these conversations occur in a very non-structured manner - over lunch, while going to get coffee. You can't do that if you live in different facilities. You can't do that if you have different measurements and different objectives. You can't do that if you don't speak the same language.
1761.123	Two different extremes of the same continuum	VAULT::CRAMER		`Wed Feb 26 1992 09:03`	32
	re: .121 You couldn't be more on track. There are two types of software development being discussed here. One is software products for external consumption, the other is interal IS systems that help run DEC. The latter type is my current field of expertise and there has been developing over the last, at least, 8 years a distressing trend. The trend has been the downgrading of analysis skills to the point where the belief is "anyone can write a good functional spec. all they have to do is follow the current methodology like a cook book." Be it DRM, DMR, Brown book or whatever, the developers have been reduced to the level of hired coders while people without training or experience are given responsibility for specification/design. It is this tendency that I rail at and which Ray Thackery mis-understood as a perception that technical gurus are goodness. Ray Doane is absolutely right in identifying some of the critical factors that come into play when trying to figure out exactly what a system should and should not do. My guess is that the two types of software development I mentioned above are plagued (gross generalization warning) the opposite problems. Internal IS has moved to the point where people are allowed to design the car because they've been driving one for 20 years. External product development has the problem where the auto-engineers don't need to talk to customers 'cause the engineers have been driving for 20 years. That is a gross generalization but I think it highlights what I think are two different realities which can be classified as Developer/User communication problems. The trick is to find the happy median.
1761.124	application to s/w career paths	PULPO::BELDIN_R	Pull us together, not apart	`Wed Feb 26 1992 09:56`	43
	Re: <<< Note 1761.123 by VAULT::CRAMER >>> and a lot of the others, too. Let me add some personal experience that confirms much of what has been said here and, I believe, points out some "work force planning" opportunities for us. I started programming just thirty years ago. For the first four of those years, I did two kinds of programming, a) I was the customer, analyst, and programmer. (MODEL A) b) I was analyst and programmer only. (MODEL B) I believe that I was successful in b) type interactions because programming was only part of my customer's need. The other parts were statistical consulting which I also provided. The customer and I discussed how much programming there would be and how much statistics so I understood his real needs pretty well. Later, I only programmed for my own consumption, which is much easier. It is also easy to fall into the trap of sloppy documentation because one can fool himself into thinking a) I am the only customer, so I don't need documentation. b) I will always know what I was doing here and how to evolve this. After I joined Digital, I had my first experience in separation of responsibilities. I was the customer and the analyst. Call that (MODEL C). For the past fifteen years, I have operated in MODEL C at Digital and in MODEL A on my home computer. I was the Materials and Planning Analyst, working as the interface with IM&T. Today, I have an IM&T title, but I still work in the Materials organization. After the long preamble, here's my proposal. No one should move from a Programmer (coding) job directly to an Analyst (engineering) job. In order to become an Analyst, one must have extended experience as the customer. Career paths for Digital Systems Architects, Systems Analysts, System Designers, etc should move through (internal) organizations which are customers of IM&T before assuming professional software engineering responsibilities.
1761.125	Why some people horde their code	TLE::AMARTIN	Alan H. Martin	`Fri Jul 31 1992 20:22`	8
	Re .102: > I have never been convinced that general within-company > restrictions on access are wise. It's a way of keeping your project from being stolen by a group with better political skills, among other things. /AHM