Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!voder!pyramid!athertn!hemlock!mcgregor From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Newsgroups: comp.software-eng Subject: Re: Personal growth and software engineering! Message-ID: <35030@athertn.Atherton.COM> Date: 17 Apr 91 18:31:55 GMT References: <1991Apr15.200458.11331@dg-rtp.dg.com> <35017@athertn.Atherton.COM> Sender: news@athertn.Atherton.COM Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor) Organization: Atherton Technology -- Sunnyvale, CA Lines: 96 In article <1991Apr15.200458.11331@dg-rtp.dg.com>, cole@farmhand.rtp.dg.com (Bill Cole) writes: > 1. What's a defect? Is it a mis-spelling? An annoying placement of a > message? A mis-mapped message? Is a corruption of a database? Is it > a crashed system? The defect-is-a-defect-is-a-defect mentality doesn't > reflect the way we view products -- software or not. A defect is something that matters, and it isn't in the way that is beneficial to you. It is something that if removed, fixed or avoided, would avoid problems or bring benefits. This is very subjective--does a mis-spelling matter? If is matters it is a defect. If it doesn't it isn't. Whos opinion counts? Obviously--the people who get to make the decisions. It could be you, it could be a senior manager, it could be a customer. It could be all of you. > 2. How do we measure productivity in rev n+1 software? That is, we > seldom deal with clean-sheet projects; we spend most of our lives refining > what we did before, maybe adding features or functionality. But we don't > get to work on completely new projects for the vast majority of our > professional lives. So how do you measure productivity/defects in that > environment? Go back to what matters to the subjective decision makers above. > 3. Who cares what the lines-per-timeframe is? or the defects-per-line > if the software is delivered per the agreed-upon schedule and with the > agreed-upon level of quality (as measured by the known bug count of various > levels of problems)? Notice that the assumption here is that the schedule > was 'reasonable' and that the quality level was 'rational' -- and that the > folks doing the developing agreed to all this. The people who care what the lines-per-timeframe are the people who want to be able to do something about it, or the people who need to assure themselves that competitors will not be any more able to do something about it than they are. As a manager, I see 2 lines an hour and I know that there are things going on that are chewing up time, besides keying in those two lines. This does not mean that the people doing the coding are bad people. Maybe that number is consistant with past history. But WHY does it takes so long? Some of that time is think time. That's good, but if I gave a person more training, would they solve problems faster? Might my competitors do just that? Would a copy of collected algorithms of the ACM help? Or am I chewing up too much time with meetings? Meetings that perhaps customers might not have? What does it mean for a schedule to be reasonable? Does it not mean mainly that it is line with historical local experiences? Might a manager agree with a schedule and quality that was consistant with the past market requirements, only to be surprised by a competitor that made a major change? What was an acceptable price/performance for a workstation before the HP 700 announcement? Will it be the same afterwards? What was the quality requirements for American cars in the 60s? After the improvements in quality by the Japanese and Europeans, can the agreements of the past continue? Managers often make judgements with limited information. They do not know for sure what the competitors will do, or what the market will do. They may agree on the reasonableness of a certain schedule, or quality plan based upon past experience. If you meet it, then everything is okay right? You are a success. If the quality is too low, or the product too little, too late, then it isn't your fault right? But will the fact that the mistakes weren't your fault make you feel better when the project or company or national industry fails. Will being a faultless victim feel good? (Digression, for ten years I worked for a major hardware vendor. The last years there I managed a project team. We delivered EVERY project on time, or sometimes earlier. We did several crash projects successfully. We even helped bail out another teams project effort that had bogged down. But the company still wasn't successful in that market, and basically exited the area, displacing the "successful" project team. It didn't feel good to be a faultless failure." In other words, it is not sufficient to do things right, you must also do the right things. And part of this means doing more than what is being asked of you, but looking over your shoulder at the competition and using your head to understand where improvements are possible by yourself, or your competitors. > We can measure and 'quantify' all day, but the bottom line is customer > satisfaction. And the perception of quality. Absolutely correct. And if you measure and quantify all day you'll never do the real work to get customer satisfaction. On the other hand, if you always put your head down and do things the way they have been done in the past without questioning how improvements might be made you can find yourself passed by competitors who make continual improvements. You must have a balance If you are merely successful in doing what is asked of you, but become a "faultless failure" victim in the end. It has happened before to many companies and national industries. The best way to avoid this, if avoidance is possible, is to look around you and question why things are the way they are, and what can change. Scott McGregor Atherton Technology mcgregor@atherton.com