Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!farmhand!cole From: cole@farmhand.rtp.dg.com (Bill Cole) Newsgroups: comp.software-eng Subject: Re: Personal growth and software engineering! Message-ID: <1991Apr19.203033.2151@dg-rtp.dg.com> Date: 19 Apr 91 20:30:33 GMT References: <1991Apr15.200458.11331@dg-rtp.dg.com> <35017@athertn.Atherton.COM> <35030@athertn.Atherton.COM> Sender: cole@farmhand (Bill Cole) Organization: Data General Corporation, Research Triangle Park, NC Lines: 95 |> > 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. My response was directed at the academic folks who use the term 'defects' without differentiation. I agree with you in general. I'd add that a defect to one is not necessarily a defect to all; and what was a nit can become a major malfunction if it comes at the end of a chain of problems or other defects. |> |> > 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. I don't understand your response. The two don't seem to map together. |> |> > 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? We should be on search for 'fat' in what we do and continue to question the process. Other examples: Will taking the group out for a day/week as a reward help the process? Are the right people assigned in the right places? Could we adjust the hours and get some overlap? |> What does it mean for a schedule to be reasonable? Does it not mean mainly |> that it is line with historical local experiences? For me, a schedule is reasonable if (1) we're getting to the marketplace in a rational time with a product that has the majority of the features needed, and (2) if the folks doing the job agree that they can get it done in that time. If I impose my managerial will and dictate a schedule which is simply not within the realm of possibility, then I'll probably fail. My feel for the work as a former technician should give me an indication of whether or not the productivity makes sense. |> 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? Yup. In fact, there's an extension to this idea which says that it may not be a good idea to be the first one in the marketplace; that way you can learn what's important -- and not important -- and move quickly to cash in on your competitor's mistakes or deficiencies. |> 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. George Patton said that you should never believe that your enemy can't do the same things you can do. Sorry to include so much of your reply, but it didn't seem fair not to. /Bill /