Hacker News Reader

Comment by aosmith | Hacker News Reader

Here's the backstory: http://web.archive.org/web/20100310163744/http://www.stsc.hi...

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.

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.

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.

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.

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.

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.

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.

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.

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.

Wow. Reminds me of a joke my dad repeated to me many years ago:

Software saved the aerospace industry. Every other way of adding cost to an airplane also adds weight.

He spent most of his career at Lockheed and Rockwell.

I guess storing all those 1's also adds some weight. It costs on the order of antimatter if you think of it. What's it like, $50 million per 1 billionth of a gram, or so?

The only storage medium I can spontaneously think of where 1s are heavier than 0s is punch cards. I hope that is not the current primary storage method in the aerospace industry.

No but it’s a good... punch... line haha

Well... technically most hard drives should change weight depending on their contents: https://physics.stackexchange.com/questions/31326/is-a-hard-...

Oh wow. And now that I read this, it dawned on me that any memory technology that is based on storing charge (like DRAM) will have actual, albeit also very very theoretical, mass differences depending on bit value as well...

The internet weighs about 50 grams: https://youtu.be/WaUzu-iksi8

Hard disks use a run-length limited encoding, so the number of magnetic 1s and 0s remains roughly constant no matter what logical 1s and 0s you store.

https://en.wikipedia.org/wiki/Run-length_limited

Nit-pick: 0s (no hole) are heavier than 1s (hole).

http://www.punctum.com/interest/punch/index.en.html

True, I should have said “weight difference”.

Some storage systems work by holding a charge, and electrons have mass.

In practical terms it night as well be 0 but in silly discussions on the internet terms it's a very small non-zero value.

Now you've got me thinking about a hash checking algorithm by weighing the punch cards hah

Interesting thought. Weighing can add an extra level of indirection ! Thinking a bit more... the same can be done in software too ?

Weighing would only be slightly better than a simple parity check (a one-bit hash). It misses common errors like transposing two adjacent characters.

However, you can get any number of additional bits by suspending the punch card from various locations along its perimeter, and measuring the angle at which it hangs.

> punch cards

Is hanging chad a 0 or a 1?

They're in superposition.

Schrödinger's bit.

Is there any kind of energy, (and thus mass) associated with the decreased entropy of structured data files on a data storage device vs random noise? I don't recall the thermodynamics of data storage being covered during my college physics class.

This is why I always advocate for the use of specialized negative binary using 0 and -1 for weight-sensitive embedded products. For optimum weight characteristics you flip all unused storage space to -1. Careful though, too much empty space formated this way will result in negative gravitational pull and something like an Arduino with a high capacity SD card will float away.

Contrasts with "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." - Bill Gates

Reply on news.ycombinator.com