Hacker News Reader

Comment by dotancohen | Hacker News Reader

The way that the fine article was worded, it seems that the engineering team knew that they needed approximately 1.5M LOC before they has started. How could they have known that? Or is it simply poorly worded?

> The ATF Team planned to develop approximately 1.5 million source lines of code, across more than 20 software development companies located throughout the U.S., Canada, and Europe.

View on HN

Used to work in missile defense at LM as a Systems Engineer, and seen similar estimations done for cost, schedule, LOC, FTEs, etc.

To get to the total 1.5M LOC, it's after decomposing the system into lower level black boxes and doing some modeling/simulation.

How many lines of code has it taken in the past to build our navigation systems, radios, weapon system A, weapon system B, etc. How much integration work is there? If its a CAN bus, the last project had X LOC for the bus architecture. Add em up, and add a big fudging factor.

There is a school of thought that says rather than look at the requirements and make your best guess at the amount of work needed to implement them, you will get more accurate results by making your best guess at the number of lines of code required, then using a formula to estimate the amount of work needed to write that many lines of code. I personally am not convinced this is really more accurate, but it does have serious adherents.

In either case, there is a final fudge factor applied to the bottom line number that upper management applies to arrive at a cost that is acceptable to them.

The variation I was taught (and it works rather well), is to look at the Requirements and estimate them in terms of T-Shirt sizes of LOC (Small, Medium, Large, XL). Then baseline your S/M/L/XL sizes into LOC. e.g., Small is 20 LOC, Large is 750, etc. From that, use your historical data (you have been tracking closely how long it takes to implement a feature vs its LOC size, right?) to estimate that say, a Small feature (20 LOC) will take 2 days at a rate of 10 LOC/Day.

It takes a lot of discipline and planning, but in the end it's the most accurate method of size and time estimation I've ever seen.

I'm sure that works reasonably well in most cases, but it is a bit of a fallacy that it take a similar amount of effort to write each LOC.

I think the idea is that, when you're measuring in units of many thousands of LOC, those differences roughly average out.

Whether that's true across widely differing parts of such a huge system I'm not convinced, but within a single more typical software project it seems believable to me.

You are correct. For reasons of expediency I did not mention that there's a "difficulty" factor which is usually expressed by a variable LOC/hour rate. e.g., Server backend code might be estimated at 100 LOC/day whereas code for an 8-bit embedded controller might be 10 LOC/day.

Somebody had a development budget, they looked up how much software developers cost, and how many lines of code per day they write, and BINGO! we have a contractual business requirement for ((budget + 20%) / dev-day-rate * LOC-per-day) lines of code.

System engineers in the defense industry have an insidious infatuation with SLOC metrics. To the detriment of many a development engineer, CMU SEI hasn't developed a better way to keep them preoccupied.

Believe it or not, there are still cost-estimation methodologies that use LOC. You somehow go from the problem, to an estimated number of lines of code that will need to be written, and then you divide and multiply that out by the number of developers per hour and their hourly rate.

Someone decided that the task was about 1.5 MLOC and used that to drive the total contract value.

Not a bad way to evaluate effort, if you believe in COCOMO (https://en.m.wikipedia.org/wiki/COCOMO). Some (most?) big defense groups maintain some metrics for past projects. LOC/man-month, complexity/cost. LOCs from COCOMO is a way to check your estimation within an order of magnitude.

The way that the fine article was worded, it seems that the engineering team knew that they needed approximately 1.5M LOC before they has started

It's possible, with highly detailed design documents. You could use something like "cyclomatic complexity" which is an older estimation methodology which is just a laundry list of small granularity features with point values attached. You add those up, while multiplying some weighted numbers together to account for interlinked complexity, then use a figure for the implementation language to come up with an estimated LOC figure. Error bars on that kind of thing are something like +/- 100%/50%. (I'm pulling numbers out of my @ss here, but I'm talking about a highly ritualized and systematized way of doing just that.)

You can get better estimates, usually by asking shops that have written the same sort of product many times before.

Cyclomatic complexity is a measure of complexity not an estimation technique (although some people do use it as part of estimation).

(https://en.wikipedia.org/wiki/Cyclomatic_complexity)

Calculating this involves working out the number of branches through the code, nothing to do with estimation. It is also very much in use today to analyse codebases, finding hotspots, etc.

Also seems pretty low for a team that size. I would love to know their cost per line...

In aerospace, a hyphen might well be worth $80 million.

https://priceonomics.com/the-typo-that-destroyed-a-space-shu...

Why is the URL referring to a space shuttle, when the vehicle lost was an expendable Venus probe (Mariner I)? It wasn't even the probe that failed, but rather the Agena (second stage on top of the Atlas) that failed.

Reply on news.ycombinator.com