There is no good way to perform a software cost‐benefit analysis, breakeven analysis, or make‐or‐buy analysis without some reasonably accurate method of estimating software costs and their sensitivity to various product, project, and environmental factors. ‐ Dr. Barry Boehm
The previous post on Source Lines of Code, set off a firestorm from the proponents of #NoEstimates.
I'd rather not estimate than estimate with SLOC
or my favorite since we work in the domains of flight avionics (command and data handling (C&DH) and guidance navigation and control (GN&C)), fire control systems, fault tolerant process control and the diagnostic coverage needed for process safety management, ground data and business process systems for both aircraft and spacecraft.
I'm no longer going to fly with any company that counts LOC as (it) shows a lack of intelligence. †
So the question is where and when are estimating the source lines of code useful for making business decisions?
Embedded Software Intensive Systems
In the embedded systems business, memory is fixed, processor speed is hardwired and many times limited by thermal control process. Aircraft and spacecraft avionics bays have limited cooling, so getting a faster processes has repercussions beyond the cost of getting a faster processor. In an aircraft cooling must be added, increasing weight, possibly impacting the center of gravity. In a spacecraft, cooling is not done with fans and moving air. There is no air. Heat pipes and radiators are needed, again adding weight.
For those with experience in rapid development of small chunks of code the get released often to the customer for incremental use in the business process that then provide feedback for the next sliced piece of functionality being concerned about the center of gravity, thermal load, realtime critical path of the executing code so it maintains the realtime closed loop control algorithm so we don't crash into the end of the runway or onto the surface of a distance planet is probably not in their vocabulary.
Business and Processing Systems
For terrestrial systems, even business processing systems, the number of lines of code has direct impact on cost and schedule. Let's start with a source code security analyzer. Those whose skills are rapidly chunking out pieces of useful functionality aren't likely to be interested in running all their code through a security analyzer before even starting the compile and check out process.
A source code security analyzer examines source code to detect and report weaknesses that can lead to security vulnerabilities.
They are one of the last lines of defense to eliminate software vulnerabilities during development or after deployment. Like all things mission critical there is a Source Code Security Analysis Tool Functional Specification Version 1.1, NIST Special Publication 500-268, February 2011, http://samate.nist.gov/docs/source_code_security_analysis_spec_SP500-268_v1.1.pdf
Development and Product Maintenance
A recent hands on experience with the need to know the SLOC comes from a refactoring effort to remove all the reflection from a code base. Those note familiar with reflection it provides objects that describe assemblies, modules and types. Reflection dynamically creates an instance of a type, binds the type to an existing object, or gets the type from an existing object and invoke its methods or access its fields and properties. If you are using attributes in your code, reflection enables you to access them.
This is a cleaver way to build code in a rapidly changing requirements paradigm. A bit too cleaver in our high performance transaction processing system
In larger production transaction processing systems, it's a way to crater the performance of the code by searching for object types on every single call for the transaction.
Removing all the reflection code structures has eliminates a huge percentage of the CPU time, memory requirements, database performance impacts - along with separating all the DB logic into Stored Procedures - resulting in the decommissioning of large chucks of the server farm running a very large public health application.
How long is it going to take to refactor all this code? I know, let's make an estimate by counting the lines of code. Do a few conversions from the current design (reflections), count how long that took. Divide the total lines of code (objects and their size) by that and we have an Estimate to Complete. Add some margin and we'll know approximately when the big pile of crappy code can get rid of the smell of running fat, slow, and error prone.
High Performance Embedded Mission Systems
High Performance Embedded Systems are found everywhere. Current estimates show they outnumber desktop and server systems 100 to 1. Most of these systems have ZERO defect goals. As well as ZERO tolerance for performance shortfalls, processing disruptions, and other reset conditions.
How do we have any sense of that the code base is capable of meeting these conditions? Testing of course is one way. But exhaustive testing is simply not possible. In a past life verification and validation of the code was the method - and still the method. Along with that is the cyclomatic complexity assessment of the code base. Another activity not likely to be of much interest to those producing the small chunks of sliced code to rapidly satisfy the customers emerging and possibly unknowable needs until they see it working.
So In The End
Unless we suspend the principles of Microeconomics and Managerial Finance when making management decisions in the presence of uncertainty, we're going to need to estimate the outcomes of our decisions.
This process is the basis of opportunity cost - that is what is the cost of one decisions over some others. If I make Decision A, what is the cost of NOT making decision B or C. This LOST opportunity is the cost of choice.
Unless we suspend the principles of probability and statistics when applied to networks of interrelated work, we're not going to be able to make decisions without making estimates.
In the four examples above, from direct hands on experience, Source Lines of Code are a good proxy for making estimates about cost and schedule, as well as the complexity of the code base when computing the inherent reliability and fault tolerance of the applications that are embedded in the software by which our daily lives depend on. From flight controls in aircraft, process control loops in everything under computer control, including the computers themselves, the assurance that the code we write is secure and will behave as needed.
If you hear some unsubstantiated claim that SLOC are not of any use in estimating further outcomes, ask when you were working a system where failure is not an option did those paying for that system tell you they didn't need to estimate the outcomes of their decisions? Haven't worked in that environment? May want to do some exploring of your own to see some of the many ways estimates are made and how SLOC is one of those in Software Intensive Systems Cost and Schedule Estimating (this document is an example of how SLOC is used in systems that are sensitive to size and performance based on the size of the code base. So take a read and possible see something you may not have encountered before. May not be your domain, but embedded systems outnumber desktop and server side systems 100 to 1)
One final thought about Software Intensive Systems and their impact on larger software development processes is the introduction of Agile Development in these domains. Progress is being made in the integration of Agile with large systems acquisition processes. Here's a recent briefing in a domain where systems are engineered. Systems we depend on to work as specified every single time.
† It's going to be a long walk for the poster of that nonsense idea. Oh yeah those building Positive Train Controls, are also realtime embedded systems developers and they use SLOC to estimate timing, testing, complexity, and many other ...ilities. Same with auto manufacturers. Maybe the Nike show company doesn't. So enjoy the walk. And BTW that OP deleted his post, but worry not, got a screen capture.
