...that we shouldn't want things like identities, families, and lives. It is a joy for us to be interchangeable work-bots. Dissention must be expunged so that we can be assimilated. Obedience is happiness!

Ninja Gaiden 1 or 2 would have been a very different conversation. The way I see it, the Aussies found a way to rack up a symbolic victory to look good to hyper-sensitive parents without actually hamstringing a blockbuster game.

I haven't seen one in a long time. My boss tells me that 7000 man-years isn't anything he shouldn't expect in a good, hard 3-day push.

Focus, focus, focus on getting that product out the door; that alone will take everything you've got. Open-sourcing involves managing a team of people who are distributed in geography and in time zones, and may not care about the mission of your business. It's way more headache than you need right now; I'd definitely not try to add that to your already-full plate.

Open-sourcing isn't really a marketing tool. Once you have a harem of happy customers, they will provide all the buzz you need, and then if you're profitable, you might have some breathing room to think about helping society.

The single biggest line item on my (and probably many people's) productivity costs is interruptions of the form, "hey, I need to answer a question that takes more than a goldfish brain's worth of thought. I'd like you to do that thinking for me."

The second would be, "As my work product, I took a big dump into our codebase. Given that I don't care about anything but going home at 5, and none of our leadership understands what I did anyway, especially since I have two monitors and therefore look smart, why don't you clean it up for me if you are interested in finishing your own work?"

I'd settle for just dumping some dead weight instead of any new technology. Really.

This is one of those problems, such as "the O/R problem," that cannot be solved because it asks an invalid question. I might suggest using it as a koan for Zen meditation.

The actual length of time a project will take arises from the complexities of the existing codebase as well as the rabbit hole of requirements. We can talk about the idea of a "spec" all day, but I've never seen requirements really, truly, set-in-stone finalized before release. Too many decision points always come up that were impossible to foresee without looking at a partially-complete version of the product. Requirements, like code constructs, are an adaptive process that continues all the way through the lifecycle, which is why the industry is flailing around for alternatives to the unrealistic waterfall model.

Thus, the set of actions that lead a team from beginning to end of a project are always, at least partially (and usually mostly) defined only as a function of the current state, and thus can't be fully predicted without actually playing out those actions. They can theoretically be partially predicted, but it's impossible to determine how large a fraction of the whole the resulting prediction is. It's almost never large enough to be considered remotely reliable.

Engineers themselves usually have a gut feeling that time estimates are a waste of time because of the need for this adaptive process. When was the last time you attempted a true end-to-end time estimate on a project where none was asked for by management? More than likely, you instead made a judgment about which path was probably the more efficient use of time, and started down that path with only a rough, order-of-magnitude guess at its length. At each step, your decision to continue was based on (1) how long it had taken so far, and (2) whether you continued to see a fruitful-looking path ahead.

I would argue that the common notion of time estimation in the industry arises mostly from the desire of outside parties (management) to create the illusion that the leaders are in control. I say "illusion" because ultimately, the main power here lies in the structure of the problem, not in any one person's hands. But the reality of being at the total mercy of a complex logic puzzle that can't be reasoned with would make most people very uncomfortable, especially those who are not in engineering. But the illusion of a "classic" hierarchical department with management and labor calms everyone's nerves and allows the workday to roll on, so we engage in activities that support it, including this charade of guessing the future.

Thus, searching for a good method of time estimation in mathematical models may help a bit, but ultimately won't get us there because it is fundamentally an emotional process. Look to the "soft" elements of team dynamics and department culture to do the rest: do people need to feel involved? Use a method where everyone contributes a number. Is the manager very controlling? Let him/her make up a number. Either way, there will then need to be a process of reconciliation between the illusion and reality, which again, is a process that depends on the emotions of the business. Perhaps a leader apologizes. Perhaps a "tiger team" is formed to improve estimation, or there is a department offsite to talk about it. It may feel unsatisfying that none of these actually brings the estimate and reality together, but like I said at first, trying to do that is asking the wrong question.

That's really the crux of all of this. The fact that the founders of both went to Stanford is hard proof of what I've always said: they are all part of a secret railroad monopoly plan hatched by Leland Stanford in the 1800s.

That's why he orchestrated the Hoover presidency and built the linear accelerator facility, which looks like the all-seeing eye when seen from the air. Google is really just a corporate front for the Stanford band, whose shadowy aim is to take over the world from their trailer, where Leland Stanford is kept cryogenically frozen!

The world, I say!