cfranz@wrdis01.af.mil (Claus Franzkowiak) (03/30/91)
In article <"910326054349.71660.412.CHE55-1"@CompuServe.COM>, 71660.412@CompuServe.COM (Eric C Aker) writes: > I just have to get in to this debate. > When I was working for a major airplane company some years ago all of > the programmers were told to give a LOC count in each weakly (sic) > report. Of course a tool was written to automatically count lines and > give differences from last week. We all grumbled and one of the > programmers came up with this great analogy. > > "Measuring progress on a SW project in lines of code is like measuring > progress on an airplane in pounds of aircraft designed. Would any > serious manager ask his aircraft designers how many pounds of airplane > did you design this week? It is true that after the aircraft is done > you can compute productivity in pounds of aircraft per manday, but it > is not a very useful number." >Excellent analogy! >The problem is measuring the progress of an intellectual product. LOC is often >used in management metrics; they, after all, have to be concerned about the >bottom line. >The problem as I see it is that often LOC measure very little. In many cases, >of course, there is a relationship: a 100,000 LOC program is probably more >difficult and complex than a 1000 LOC program. There are some good empirical >studies out there to suggest this. However, we've all written programs that >are several hundred lines long - including design, testing, etc. in a few >hours, and we've written 40 LOC that may have taken weeks to develop and test. >So, the question remains (and I'd like to have some answers for my Software >Engineering class).... What is a good measure of programmer productivity? >(The only one I can think of is the amount of coffee/Mountain Dew/JOLT consumed >per hour.) -- George C. Harrison ----------------------- ----- Professor of Computer Science ----------------------- ----- Norfolk State University ----------------------- ----- 2401 Corprew Avenue, Norfolk, Virginia 23504 ----------------------- ----- INTERNET: g_harrison@vger.nsu.edu --------------------------------- I like this discussion. But first of all, a manager should be interested in how many LOC are working. A "finished" program with 10K of LOC and 50% of rework does not make the programmer more productive, but they should be subtracted from the 10k LOC. If one programmer implements a procedure that operates in real-time, e.g. the scheduler of an operating system, he/she might use a straight forward approach and produces a lot of LOC in a short period of time. Another programmer might spend a lot more time in the design phase of the procedure that works more efficiently and results in a more competitive product. Therefore the second programmer is more productive than the first one. What is a good measure of programmer productivity? There is none! There are too many variables that have to be put together in one single equation that measures the amount of productivity. Here are some of them: 1. People Factors (years of experience, language experience, morale of programmers, quality of management etc.) 2. Process factors (top-down design, inspections, tools, optimizing compilers etc) 3. Product Factors (requirements, complexity etc) 4. Computer Factors (response time, hardware problems, storage constraints, etc) There are a lot more factors. Is anyone interested in quality programming? Quality programming as described by M. Fagan will reduce the amount of rework and naturally increases productivity. claus franzkowiak robins afb (912) 926-7714 cfranz@wrdis01.af.mil
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) (03/31/91)
In article <399@wrdis01.af.mil>, cfranz@wrdis01.af.mil (Claus Franzkowiak) writes: > In article <"910326054349.71660.412.CHE55-1"@CompuServe.COM>, 71660.412@CompuServe.COM (Eric C Aker) writes: >> When I was working for a major airplane company some years ago all of etc. >>The problem is measuring the progress of an intellectual product. LOC is often >>used in management metrics; they, after all, have to be concerned about the >>bottom line. > etc. >>So, the question remains (and I'd like to have some answers for my Software >>Engineering class).... What is a good measure of programmer productivity? > >>(The only one I can think of is the amount of coffee/Mountain Dew/JOLT consumed >>per hour.) > >> -- George C. Harrison ----------------------- > I like this discussion. But first of all, a manager should be interested in > how many LOC are working. A "finished" program with 10K of LOC and 50% of > rework does not make the programmer more productive, but they should be > subtracted from the 10k LOC. The keyword is "should." What IS good management practice in this situation? Maybe this ought to be in comp.softwareengineering... whatever, but after all this is what Ada is all about. > Here are some of them: 1. People Factors (years of experience, language etc. > There are a lot more factors. Sounds like COCOMO. I agree, these are important factors, but how does the management of programmers on a day-to-day basis reflect these things? > Is anyone interested in quality programming? > Quality programming as described by M. Fagan will reduce the amount of rework > and naturally increases productivity. > > claus franzkowiak Perhaps we are still in the bind of not really thinking that software production is still an intellectual process. George.... -- George C. Harrison ----------------------- ----- Professor of Computer Science ----------------------- ----- Norfolk State University ----------------------- ----- 2401 Corprew Avenue, Norfolk, Virginia 23504 ----------------------- ----- INTERNET: g_harrison@vger.nsu.edu ---------------------------------