back
5 comments
There's absolutely nothing special about what they're able to achieve once you look at the price. Many, many organizations could do just as well if they had the budget.

$35mm/year to maintain 420kLOC.

If you assume that each person costs about $150k/year in terms of salary, benefits, overhead, etc then you've got 233 salaries. In actuality they employ 260 people (from the article), so this math is pretty good.

What this boils down to is say 100 people writing code and 100 people verifying it (and 60 managers, administrative, etc). That means ownership of only 4kLOC per person. And that's maintaining, not writing from scratch. If turnover on code is 10% per year (and that's probably high!) then that's 400 lines of code you have to write every year.

400 lines per year is 40 lines per month. Two lines per day. Coding by proof at this kind of scale is actually practical, which is how they're able to catch so many bugs. You can fuzz test it, you can discuss it with your colleagues, you can agonize over the specific math you're supposed to be doing. You can do all kinds of things that people who have to produce 10x or 100x the code don't have the luxury of doing.

Given the budget I would expect nothing less.

$35mm/year to maintain 420kLOC. [...] Given the budget I would expect nothing less.

What's impressive isn't the LOC per dollar (or person), even at that level of reliability, but the functionality (and reliability of functionality) per LOC. It's what that 420 kLoC does. They've managed to get a lot of functionality relative to code size... because they know the cost of excess code.

I wouldn't be surprised if most Silicon Valley companies have 420 kLoC after a couple years, not a single line of it being something you'd want to bet your life on. The difference is that 420 kLoC of "Agile" code written under deadline culture (perpetual "sprinting") with stack-ranking is going to amount to nothing but 3/4ths of a shitty product-- not because it isn't enough code, but because the code is so unreliable.

As it were, there are plenty of startups with $35M per year budgets (or more) that aren't writing high-reliability code or anything even close to it.

> What's impressive isn't the LOC per dollar (or person), even at that level of reliability, but the functionality (and reliability of functionality) per LOC. It's what that 420 kLoC does. They've managed to get a lot of functionality relative to code size... because they know the cost of excess code.

I don't know that I agree that the code is particularly feature dense or anything. It might be, or it might not. Just because it flys the shuttle doesn't mean it's a miracle of efficiency. Hell, it might be really inefficient for all we know. They might do clipboard inheritance all over the place because that's easier than trying to accidentally not break a "general purpose" function when making a particular change.

Also, they're not writing 420kLOC every year, they've slowly accumulated that much code. The turnover I would suspect is 10% a year or less. Might only be 3% a year.

What I was trying to say is with that level of funding versus the amount of features that they have to deliver (little/no interfaces, no database, no scaling, no sharding, no data sanitization, etc) it's much, much easier to get things right. This is basically firmware and the hardware is known so it's much, much easier to get it right.

The web is so often broken because there are dozens of different standards by different institutions that are adhered to in varying degrees by many thousands of different projects running on a multitude of hardware. Getting stuff so right for the space shuttle is impressive for sure, but look at the kind of comparison you're making.

The use of the present tense to refer to Shuttle launches is a bit odd at first - it looks like this article actually dates from 1996. Was surprised to find out that Fast Company was that old, but there you go - apparently they launched November 1995.
Been posted many times before [1].

1. https://hn.algolia.com/?query=they%20write%20the%20right%20s...