Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!jethro!exodus!appserv!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: <1991Apr23.171952.12@dg-rtp.dg.com> Date: 23 Apr 91 17:19:52 GMT References: <35017@athertn.Atherton.COM> <1991Apr15.200458.11331@dg-rtp.dg.com> <+CTADP6@xds6.ferranti.com> Sender: cole@farmhand (Bill Cole) Organization: Data General Corporation, Research Triangle Park, NC Lines: 39 |> > Measurement is a useful approach in some circumstances. However, if |> > measurements don't "tell you what to do" about your process they can |> > be misleading at best. |> |> Measurements are unlikely to "tell you what to do." Most "misleading" |> is really misinterpretation; i.e., the failure to do the proper analysis, |> and then use the data correctly, perhaps to improve the measurements. The danger is that we measure what's easy to measure and neglect the difficult things simply because they are difficult. Or we choose to measure based on what we expect the conclusions to be (i.e., a method used widely in the hard sciences). |> > 1. .... The defect-is-a-defect-is-a-defect mentality doesn't |> > reflect the way we view products -- software or not. |> |> Who's "we?" (I believe defects are usually classified by level of severity.) The comment was aimed at the academics who use the word 'defect' very loosely; you and I are in agreement -- as are a mess o' people who responded. |> > 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 ... |> |> Who cares? The banks, for one. If you have to hire twice as many people |> to make that agreed upon schedule, and your bottom line starts showing |> up in red, you won't be around to sell another high-quality product. This is a point of view I had not considered, but it is certainly valid. My 'out' is the 'reasonable phrase. We make assumptions as managers that our folks can produce software at some sustainable rate with occasional ventures into hyper-sustainable and we gauge that productivity on experience. The best way I've found to be 'reasonable' is to involve the folks building the software in the process so that the schedule is in some large measure their doing and not something imposed purely by 'management'. But I do agree with your point. /Bill Disclaimer on file...........