What are Acceptable SLoC Rates?

Question

This is not a question regarding the quality of the SLoC metric. I accept it as a limited, inaccurate, or even poor metric.

That said, I am looking for data that indicates what reasonable rates for software development given SLoC. Of particular interest are rates for different government agencies, but any insights will help.

Clarification

I have already developed a software application and it is ready to ship. The price was previously set by contract and is not in dispute. However, the accounting team is looking for a numeric reason to give their stamp of approval. These people do not account for skill or knowledge required, learning curve, generated code, efficiency or anything else. They have already been presented with valid metrics that show the "cost savings." We saved them 80%. But now we are required to justify the remaining 20%. They have been given other cost estimates, but that is not sufficient. So, I am trying to appease the bureaucracy with something to which it might relate.

Answer 1

In Software Estimation: Demystifying the Black Art, Steve McConnell presents a table that is adapted and extended from Measures for Excellence: Reliable Software On Time, Within Budget, Industrial Strength Software, and Five Core Metrics: The Intelligence Behind Successful Software Management for line of code per staff-month for different kinds of software. This table presents the low, high, and nominal values for different types of projects and total overall size (in lines of code, ranging from 10,000-LOC to 250,000-LOC).

Below, I summarize this table with the range of the highest high productivity rate, lowest low productivity rate, and range of nominal rates in parenthesis:

• Avionics: 20-1,000 (40-200)
• Business Systems: 100-18,000 (500-3,000)
• Command and Control: 40-3,000 (80-500)
• Embedded Systems: 20-2,000 (80-500)
• Internet Systems (public): 100-10,000 (200-1,500)
• Internet Systems (internal): 200-18,000 (600-4,000)
• Microcode: 20-800 (30-200)
• Process Control: 80-5,000 (200-1,000)
• Real-Time: 20-1,500 (40-200)
• Scientific Systems / Engineering Research: 80-7,500 (200-1,000)
• Shrink Wrap / Packaged Software: 70-5,000 (200-1,000)
• Systems Software / Drivers: 40-5,000 (200-1,000)
• Telecommunications: 40-3,000 (90-600)

As always, it should be noted that your organization's internal data will be more useful, as it accounts for your methods and procedures. Data gathered from wide surveys tends to be more noisy since it includes a wide variation in engineering skill, process, tools, and so on.

Note that this doesn't account for other source of variation. For example, programming language and environment do matter. Reuse of existing components matter. Experience matters. General complexity and variability matter.

Answer 2

As quick answer: "Roughly 1 screen, per team-member, pro day" of tested (debugged) code.

So, about 24 lines in the 70/80's. And up to 50 lines nowadays.

But it is very depending on how development is organized! E.g introducing lean/agile/scrum (correctly) may improve those numbers by 30%.