Hacker News Reader

There's also the dynamic of feeling the need to do more, having learned from previous mistakes.

My employer's first hit game was shipped in 5 weeks by one full-time programmer and one full-time artist. It took three years to become what it is now.

Now, when we start a new game, we worry about over-the-air downloads and updates. We think about monetization. We work with testing partners. We need privacy policies. We need Facebook integration. We need localization (English, French, Chinese-Simplified, Chinese-Traditional, German, Italian, Japanese, Korean, Portuguese, Russian, and Spanish). And on and on ...

None of this is explained by a growing team, nor by outsiders brining in their biases. Instead, we feel we need to do more to avoid the mistakes we made in the past.

Is this a maladaptive, or is it a realization of the scope of the problems we're trying to solve?

No one dies if we ship a brutal crash and data corruption bug. I love rapid prototyping, but I think new-space is realizing that rapid development means $100M, not $10M invested.

An interesting aspect is that NASA gets criticized from both sides. Here Carmack is basically criticizing NASA for not taking enough risks, being too cautious in the meticulous engineering instead of whipping out a saw and trying something. But whenever something goes wrong and there's an inquiry, the inquiry always blames NASA for being too seat-of-the-pants, not doing enough proper engineering and analysis of safety margins, not following procedures to the letter, etc., etc.

In American culture, the death of one person is typically considered unacceptable, and "we will do everything to ensure it never happens again." To date, NASA has flown many more manned missions than its private competitors. Most unmanned missions can have their cargo and vehicle replaced (albeit at great cost), but from the first-world view of "every life is precious," the same cannot be said of manned missions. So there is a fundamental, qualitative difference between the two types of missions and organizations. You can well imagine what will happen each and every time a human life is lost on a private space mission.

Will we ever consider it the cost of doing business? Probably not, except for military missions--and in the context of going to Mars, we might see more of those.

"Here Carmack is basically criticizing NASA for not taking enough risks [...]"

I understand your point, but I think it's important to take this in the context of what type of risk is being discussed (i.e., payload-only).

"We got to the point, where, we were scraping by, I mean, we had an operating profit, but it was doing contract work for other people, and I reached the conclusion that we just weren't going to get where we needed to go with that.

There's this tempting thought, that, if you work for contracts people, and you pick the right contracts, you'll be developing things that you wanted to develop anyways, that it will help you towards your goal. [...] It wasn't working for us. We were keeping the lights on, we were building rockets, but they weren't the tasks, the things that we needed to do."

That was about 2 years ago. They got side-tracked. They moved away from their core competency of what they needed to do, and started taking on outside work for what they thought would supplement their efforts, but it ended up moving them away from where they needed to be, and the added process requirements, as John said, "[...] it definitely slowed us down."

Clearly, when you go into human spaceflight mode, you are going to want to have a lot of well-defined, rigorous process in place. However, they were dealing in payload-only scenarios at this point, with entities that knew the "at risk" status of the launches. In John's words:

"They were sort of like, 'at your own risk'... you can put 'em up, you might get your payload back, but there's a good chance we're gonna crash. [...] They knew it was at-risk, and we didn't take their money when we didn't make a successful flight."

Given what they were doing (i.e., payload-only), this is the context in which he was saying that, "[...] NASA loves seeing all this stuff, it gives everybody that's contracting a good set of warm fuzzies to get stuff you hold in your hands on the engineering documents [...]"

I do not know this as fact here, as I am speculating, but it is possible that they were simply in the mode of iterating to their best ability, with the concept of operations being, "Let's rapidly prove what we can do in the payload launch and recovery area, and once we get funding, we can scale up the process and procedure aspects required for human spaceflight."

It would be interesting to hear John's comments on this topic, for sure... but in summary, from the context of his comments, I think his line of reasoning was perhaps, "Why are we taking on all of this contract work and getting slowed down in process for payload-only scenarios, when we could be building, launching, iterating and learning?"

There's a large difference between experimentation and not properly vetting a vehicle containing living things.

I've seen that phenomenon a couple times with people from Microsoft; I wonder if it's true of Googlers in some other way, too.

I'm curious, what behaviors (for good or bad) do you see that people of Microsoft bring to other companies?

In my experience

1. Put all the code into the database

2. Everything is or should be xml

What the hell part of Microsoft were they from? And were you able to get the answer to that question before they were shot?

Given the amount guys like this[1] that work at Microsoft love XML, it sounds pretty reasonable. Actually liking the XML docblocks though is taking it a bit too far. There's a lot of things I dislike about Java, but one thing they got right² (and almost everyone else used after) is their documentation blocks. When using Visual Studio I have to make the syntax color for XML elements of the blocks I generate super contrasting (usually really dark) with the documentation inside just to read it without making my head hurt.

> During the years I’ve seen a lot of different ways of commenting code – some good and some bad. My personal favourite way of commenting code is by using the XML comment feature of C# and VB.NET, but the important part of commenting code is not how you do it, but what you write in them.

[1] http://madskristensen.net/post/The-what-why-and-how-of-XML-c...

² Java may not be the first, but it's the first language I saw to use that style

It's funny to read about the Microsoft developer culture now vs. when I left fifteen years ago.

MSFT was the PayPal, Google, etc. of our generation in Seattle. It spewed out startups of FYIV people in a short period of time.

At the time, it was very disruptive to hear that "ex-Microsoft engineers" were entering a market. There were a few things that seemed pretty common in the groups with which I had contact. (SQL, LAN, VC++, etc.)

1) QA as a first class function. SDETs were awesome, and they tried to staff projects with about two for each SDE. Testing tools were automated and accounted for huge amounts of code. Compatibility labs were huge. Breaking the build would be just short of a flogging offense.

2) A focus on maximizing productivity. Spend the money on the desk that can be raised or lowered. Spend the money on the newest, latest computers, and give them to anyone who asks, as many as they think they need. Locate beverages very close to everyone and subsidize outside businesses to provide food services. Give everyone a window office. It made it a lot easier to stay there from 8am to whenever. This also led to the diaspora of startups.

3) Scary-ass yelling matches in the hallways. People who had always felt they were smarter than the jocks and popular people in their youth were suddenly capable of establishing dominance by insulting other people, their intellects, and especially their work.

4) Readable code over clever code. This led to a lot of typedefs like LPCSTWCSRARSARTARSTA[1] and Hungarian notation[2]. So if you see MyMethod(lpszName); somewhere, you'll know where that came from.

People would leave after vesting (sometimes before and sometimes long after) with the idea of creating a product of their own with the good things that Microsoft taught them and without the bad things that they hated.

Very much like when we start thinking about having kids with the intention of not making the mistakes our parents did.

[1] Yes, Colemak.

[2] https://en.wikipedia.org/wiki/Hungarian_notation

Some of the coding style from Google carries over.

// TODO(pjscott): provide a concrete example of this.

I'm also curious to see how SpaceX makes the transition to producing man-rated production vehicles. When someone at NASA says "prove this is safe", that forces a lot of the structure and painstaking process back in.

SpaceX's rockets are already "man rated" by default, or is designed to be man-rated.

True, I guess the Falcon-1 was their non-man-rated testbed.

Elon wants his rocket to be man-rated so he can ride it to Mars. The fact that NASA needs to get the ISS is just gravy.

To be fair Carmack also comes with his own cultural baggage from Id Software. Wanting to keep the team small, not setting hard deadlines, using a new generation of the engine for each game etc.

It worked, didn't it?

Not really; The development time seems to be getting longer. Quake/Doom 1 took a ~year. Doom 3 was 3 years, and now Rage the latest title took 7 (!) years.

Right, but look at the team size as that happened. I'd posit that moving away from the team structure he advocated is part of the cause of those delays.

I am not entirely sure how good Carmack was for the company—the tech engine yes, as the director of a corporation, not so sure.

Agreed. It's obvious now that losing Romero was a tremendous blow to the company, creatively.

(Was not obvious back when it happened though, at least not to me.)

And look at the scope.

What do you mean? All their games were aimed for the same ~12 hour play duration. Rage was no exception.

The amount of content you have to produce for 12 hours of Rage is much greater than for 12 hours of Doom

Theres a lot of great articles on Scaled Composites (both before and after they won the X prize) that describe the culture and what it was like to work there.

http://www.wired.com/wired/archive/11.07/space.html

They seem very different from the "NASA" mentality, and much younger and more startup-focused. Very (extremely!) small team, given what they accomplished.

They also lost some people to some kind of test accident. I'm not saying this to point fingers, but to remind people that in aerospace, you're not dealing with. "Oops, I ran the wrong build configuration. I guess I'll just restart."

http://www.knightsarrow.com/rockets/scaled-composites-accide...