How long have we all heard that the productivity of the average software engineer in the United States is 7 lines of code per day? That’s it – that’s all we know. That is the extent of publicly available productivity data. Furthermore, many software professionals and managers interpreted this productivity as meaning 7 lines of code per day during the coding or programming phase only. To any self-respecting programmer, that was just absurd and lacked any credibility.
Well, the fact of the matter is there is little other information available that everyone can access for purposes of benchmarking individual performance and estimating. Data does exist however, particularly as collected by software project management consultants from projects they have supported and observed. However, in general, because of the proprietary nature of the data, the data can not be publicly released.
We at the DACS are asked frequently to provide facts about various aspects of life-cycle performance within the software industry, with very few sources to go to to find the information. So when Donald Reifer’s original article“Let the Numbers Do the Talking” appeared in the March 2002 issue of CrossTalk, I felt we finally had a reliable source from which we all could use to benchmark and estimate. For that I was very thankful.
Donald Reifer has updated that excellent 2002 article and has agreed to publish “Industry Software Cost, Quality and Productivity Benchmarks” in this issue of the DACS Software Tech News. This article first examines software productivity information, and characterizes productivity by application domain as well as compares productivity between the US and foreign regions. It next reports on cost data by application domain and language levels. Based on the most popular life-cycle models, it then reports on the distribution of effort and schedule by phase. Next, Mr. Reifer discusses typical software support costs, software quality information, and concludes by examining the trends in software improvements . So are we still at 7 source lines of code per day?
I have always found it very strange when others have referred to software testing as an art. As far as I know, I did not take any art classes at engineering school, and I feel I know a little about testing. James Whittaker’s article “Software Testing as an Art, a Craft and a Discipline” sets the record straight. Software testers are some of the most skilled people I know. I do not think of them as artists.
The next article titled “Independent Verification and Validation of Neural Networks – Developing Practitioner Assistance” by Dr. Laura Pullum, Dr. Marjorie Darrah and Mr. Brian Taylor examines NASA’s IV&V Facility’s initiative to develop a software assurance methodology for neural networks. The “black box” and highly mathematical nature of neural nets requires a different V&V approach versus traditional software V&V.
Software rejuvenation was not a discipline I was aware of before I read Larry Bernstein’s and Chandra Kintala’s final article “Software Rejuvenation and Self-Healing”. Rejuvenation is a strategy for improving the reliability and trustworthiness of a running software system. A related article (“System, Heal Thyself” by Matt Hamblin) on self-aware computing can be found on the Computerworld website (http://www.computerworld.com/ Quicklink #43636) in which the author identifies self-healing systems as an emerging technology.
As usual, we encourage your feedback on this and every issue of Software Tech News.
