The Commodore 64 was right at the cusp of technology where a device could be almost fully understood by a dedicated layperson. If you picked up the Commodore 64 Programmers Reference Guide, you got 504 pages (1.4 lbs) of technical data, including a full system schematic. Low-level programming involved tweaking memory locations that were (effectively) hard-wired to chip pins, directly manipulating the state of the SID or modem chips. Want to watch tape I/O coming in through the bus? Just watch the right memory location.
Today's systems are far more powerful. But I bet most professional developers can't say they fully understand all of the timing, pipeline, memory I/O, bus architecture, video pipeline, and everything else that makes these machines great. There's a lot of "black box", even for the experts. Read Abrash's Graphics Programming Black Book Special Edition if you want to see how much there is to know about optimizing even a single function in what is now a 20 year old machine.
The power of computing comes from abstraction. But the Commodore 64 (and the Apple ][) marked a tipping point when you could dig into the abstraction as a motivated beginner and strip away the layers until you were dealing with the bare metal. And there is power in that understanding. A bottom-to-top stack of knowledge that helps develop mental models that make more complex systems easier to understand. While my daughter has a very powerful laptop for school, way more powerful than a C-64, it highly unlikely that she or any of her peers will be able to peel the onion back to the physics of electricity like my generation was able to.
So I'd rather have today's tech. But I'm glad that I got to spend a lot of time with a C-64 in my youth, or I'd be nowhere near the programmer I am today. That's where the nostalgia comes in. Greatness in (relative) simplicity.
I wouldn't make a comment at all on this. But I will. I also hate the term tolerance, and prefer "acceptance". Tolerance means you hate something, but you deal with it anyway. I don't tolerate tolerance.
Your boss is making a financial argument for outsourcing. The only way to counter this, if you want to counter it, is with another financial argument against outsourcing. Despite the great many technical reasons not to outsource (and a few possible reasons in favor, perhaps), the decision that was made was a financial one. So if you want to argue against is, you need to be arguing in the same domain.
Here's my financial argument in favor of not outsourcing.
When you outsourcing, you are paying an external company to grow the necessary knowledge, skills, and ability to ship a software product. You are accruing zero of these assets to your company. When you have completed the project, you have generated one tangible asset, and zero intangible assets. All of the intangible assets are now owned by the party that you used to create the product. Furthermore, you have increased the value of the vendor, and thus you have increased the rate which that company can charge. And you can bet that this will be passed on to you in future product negotiations.
Inversely, with an in-house staff, the so called "extra cost" of staffing and benefits, if your environment is healthy enough to lead to employee retention of a reasonable level, leads to the accrual of in house knowledge on a wide range of topics. These include, but are not limited to: software development methodologies, planning, user interface design, software quality assurance, scheduling, testing, source code control, building reusable components, and many more. As the team matures, future products cost less.
So, in economic terms, you can outsource and pay a vendor less for the current project, adding value to that vendor. This will result either in escalating costs over time with the same vendor, or the continued use of a new vendor, and each new product will bear the cost of being a version 1 product with no institutional knowledge or economies of scale. Or you can keep things in house, pay more up front as the team develops the initial products, but with proper management you'll have a team that will produce products faster, with more personal investment, and higher quality, with a much smaller incremental cost over time.
Mean TIme to Douchebaggery : Have your boss recruit some internal people to call your department with simple but real problems, and act like users who don't know anything. Record how long it takes the customer support rep to start acting like a complete douchebag. Longer times are better.
A-hole Ratio: As the manager, you should really know who the biggest a-holes on your team are. Determine if that's having a negative impact on other members of your team. Calculate the a-hole benefit (Tickets Closed) vs. perceived a-hole cost (lost productivity in tickets).
Both of these have a direct impact on your department's productivity. If people are individually productive but bad for business as a whole, get rid of them. But if they are "that good", maybe you need people who can better work with these a-holes.
Can they be gamed? Sure, by being less of a douchebag, or less of an a-hole. Sounds like a win-win.
Even CoreAnimation is not beyond the "copying" argument. Microsoft shipped DirectAnimation years ago. Here's a link to the press release.
But this entire argument is completely useless. There are a number of skills at play when it comes to building and shipping any techology. First, a company needs to see an opportunity. Then, they need to design the right product for the market. Then they need to implement the product so that it can be easily used and make sure it's flexible enough that users can mould it into their products. Finally, the technology must be correclty marketed.
Fail at any of these, and you'll end up with a technological dead end. But that doesn't mean that somebody else didn't see the need as well, or that somebody else might not implement a better framework. That's supposed to be the beauty of our industry. There is room for competition and innovation, and no two products will hit the exact same sweet spot with a user base.
It doesn't matter who did it first. It matters who does it best for you. If I'm forced to code only on Linux, then I can tell you that CoreAnimation is not the technology for me. So I'll be looking for some competition. If I get to use OS X, I'm sure CoreAnimaiton will be useful. And if I'm on Windows, welll, DirectAnimation is dead. So I guess I'm screwed.
I don't care who was first, or who copied who. I need techology, and the capabilites of any library or feature I can use are highly dependent on the capabilities of the platform itself. If my OS provider can keep rolling out new features that help me write better software, I'm all for it. Even if they are copying somebody else. Where would any art form we have today be without the copying of features? Music, painting, storytelling; all art relies on a shared context. Great art works from there and pushes the boundaries. And I believe that coding can be an artistic expression. So I expect great programmers to borrow from each other, and then push those ideas in new directions.
We can argue which company's new direction we like best. But who is copying who? I don't care. I only care who is making the technology that I can use to write my software.
Like most arguments, the real answer lies somewhere in the middle and changes drastically depending on context. I have worked on projects where there was far too much up-front planning, and on projects where there was nowhere near enough. I've seen agile methods thrive and fail, and I've seen waterfall thrive and fail. There is no single methodology that maximizes the possibility for success.
What will work for your project depends on the scope of the project, the needs of the customer, and the team involved in the development. And, of those, I'd say the biggest factor is the knowledge and skill of the team. Not just in coding, but in understanding the project space and having a background in what has and hasn't worked in analogous conditions.
One key element is having a technical decision maker who is also a good leader. This person must be able to analyze the current situation and always be working to advance progress. There are always conflicts in a major project, and having a single decision point (or a highly functional group of such people) is fundamental to success.
If you decide to use a front-loaded design process, you need somebody who can reign in the scope of the project. They must be able to figure out when it is time to start documenting and planning and begin the work. I once interned at a bank, and watched a team do four months of eight hour per day meetings to plan a new system. They were still doing it a year later. The goal of a front loaded process is to establish a solid framework for the project, but if it never gets started, it's a waste of time.
Similarly, agile methods fail if you don't know what you are working towards. That's why the decent Agile books all spend a lot of time on user stories, use cases, and planning short term goals. You buy in at the beginning to spending a lot of time refactoring code. Which is an easier sell to management than saying "We're going to write a lot of code, and then rewrite it constantly, even when it works."
Both work, and both can fail miserably. It's the requirements of the project and the team that indicate which you use. If I'm working in an area where code audits are likely and I'm dealing with regulatory oversight, I'm front-loading the design. I want as many i's dotted and t's crossed up front, if only to legally cover myself and the bill-payers. And if I'm putting together a web site that I want to evolve over time, I'm going Agile.
But in either case, I'm using as many techniques as I can from any style that helps. Agile style unit testing writen by the dev team instead of the testers at a bank? You bet. Sending my developers out to view the end users to do a process analysis before beginning an Agile project? Hell yes. Continuous integration? Always. The key is flexibility. Observe the team and the software. Watch what is working and what doesn't. And continuously feed that information back into the process to improve it.
Good software is written by highly technical people who have the ability to communicate, led by a decisive and intelligent person who can comprehend and mesh the personal and business needs of the team, the users, and the project.
No matter how much up-front work you do, you can never capture the entirely of the project. You must be flexible. Good software is never an academic exercise. It's an organic process. Like all processes, you can control the reaction with the right inputs and environment.
When we reach the day that I can write a spec and hand it to two teams of developers and receive exactly the same code from both teams, I will leave the industry and never code again.
It's a good thing that Google launching a government search site. I've been looking for the US government for years, but haven't been able to find them. This would have really have been useful last year during Katrina, since I know a lot of other people were looking for the government then as well...
Oh, wait, there they are knocking on the door now. Guess I don't need the government search site after all.
The language you choose to learn is irrelevant. Like many fields of knowledge, the most important thing you can do is create a mental model of a computer that allows you to deduce more information.
So don't think in terms of a language. Pick a language to learn, but then try to understand what that language is actually doing. If you break down the standard C "Hello World" program, for example, you'll have tons to digest. When I define a string, what does the compiler do with it? How does it get passed to the printf funciton? What is a pointer? How does the compiler take my text and turn that into executable code? If you pick another language, you'll still have many of the same quesitons. The language is irrelevant.
So pick a task that you are passionate about. Pick a language that sounds interesting to you. And then start trying to solve the problem. And when you find that your mental model is insufficient, extend the model so it maps to your new knowledge. When you decide to learn a new language later on, odds are that 80% of your model will still apply.
I've seen a lot of people who learn C, and then move to another language and can't figure out why they don't need to end lines with semicolons. Or they don't understand how Java can do without pointers when they always needed them in C for structure arguments. The problem is not that they are stupid, it is that they don't really understand what is actually happening in the system as they code. Think about this from day one, and you'll have a much easier time of it.
And I'm not suggesting that you understand every nuance of the system. Odds are you be worrying about caching characteristics or interrupt timing for your first 50 or so projects. Many professional developers are clueless about the real hard-core system details. But the succesful ones all have a sufficient mental model for the level of work they do. And that's how they can adapt to changes in technology, languages and all things programming related.
Because, of course, all FUD is liberal. Calling something "liberal" doesn't make any points for you, it just makes your argument partisan. And that takes away any power you might have had to change the minds of "liberals" who might read it, no matter how good your data may be.
If you want to convince a liberal they are wrong, don't call them a communist. If you want to convince a conservative they are wrong, don't call them jack-booted thugs. Just make your point, and if there is intelligence there, it might stick. Otherwise, you're just wasting bandwidth.
In the actual article, note that the statement: It would cover the 20 years in the life of Luke Skywalker growing up that remains a mystery to most film-goers. is not in quotes. That means it is quite likely that the writer was trying to explain to readers who may not be SW-savvy that between episodes three and four of the film saga means the period of time when Luke was growing up. So we only know the time period. We also have "at least a hundred episodes", which tells me that they probably have a four year story arc and hope to syndicate the series.
So far we have hundreds of comments criticizing the content of a series that is not even being written yet, based on what appears to be a poorly written web article that summarizes an interview that most of us have probably never heard. Let's hold off on destroying Lucas and the series producers until they actual give us something to destroy.
What I learned from this article is that while most people (including myself) do not like what Lucas did with Episodes 1-3, there is still a lot of excitement, or at least fan energy, in this franchise. Which makes it ripe for a TV series, wouldn't you think?
Enterprise did not ruin the Star Trek franchise. Bad writing, a failure to create compelling plot lines, and a complete lack of vision ruined the Star Trek franchise.
If this show has a good team with a vision and the ability to execute, the show will be good. Sure, we'll all argue whether it's "The One True Star Wars" or not, but if it's compelling, people will watch. All the "Star Wars" brand gives them is a built in larger starting audience, more hype, and a huge set of expectations to live up to.
I've got an iBook, and there's no way I'm upgrading to this rev of the MacBook Pro. Have you felt the heat that comes off the bottom of those things? I checked out all the floor models in the local Apple Store, and every one of them was almost too hot to hold on to for more than a few seconds. The extra horsepower and promise of decent Windows perf under a new VPC in the future sound good, but that needs to be offset by the blistering of ones thighs.
The reason for a Halo2 port seems obvous:
The goal is to sell more Xbox 360's. So far, there is no killer app for the console. Halo 3 is the obvious current front-runner. But only gamers who own an Xbox or with friends who own an Xbox have been able to play Halo 2. So the excitement is curently limited to customers who are already fans of the Xbox.
If Halo 2 is available for the PC, however, then the audience for the game opens up. If the PC version is done well, it can drive more people to the franchise. Which means that the number of people who anticipate Halo 3 increeases, the buzz increases, and hopefully more hype means both more console and title sales and the stealing of PS3's thunder.
The timing of hiring developers now, however, makes me question when they would expect to ship Halo 2 PC. If Halo 3 is coming out 'the day PS3 ships', then I doubt the port will be ready to ship before Halo 3. So I'm suprised they are hiring people this late.
I think a Halo 2 port to the PC is a no brainer. So is selling it at a loss-leader price, like $30, to increase sales and therefore the potential Xbox purchaser market. But the timing, that's throwing me a bit. i'd expect this to be almost ready to ship by now. That would the product to hit the shelves a month or two before Halo 3, and work the buzz. Unless MS knows something about PS3 that we don't.
Slashdot Mirror
The Commodore 64 was right at the cusp of technology where a device could be almost fully understood by a dedicated layperson. If you picked up the Commodore 64 Programmers Reference Guide, you got 504 pages (1.4 lbs) of technical data, including a full system schematic. Low-level programming involved tweaking memory locations that were (effectively) hard-wired to chip pins, directly manipulating the state of the SID or modem chips. Want to watch tape I/O coming in through the bus? Just watch the right memory location.
Today's systems are far more powerful. But I bet most professional developers can't say they fully understand all of the timing, pipeline, memory I/O, bus architecture, video pipeline, and everything else that makes these machines great. There's a lot of "black box", even for the experts. Read Abrash's Graphics Programming Black Book Special Edition if you want to see how much there is to know about optimizing even a single function in what is now a 20 year old machine.
The power of computing comes from abstraction. But the Commodore 64 (and the Apple ][) marked a tipping point when you could dig into the abstraction as a motivated beginner and strip away the layers until you were dealing with the bare metal. And there is power in that understanding. A bottom-to-top stack of knowledge that helps develop mental models that make more complex systems easier to understand. While my daughter has a very powerful laptop for school, way more powerful than a C-64, it highly unlikely that she or any of her peers will be able to peel the onion back to the physics of electricity like my generation was able to.
So I'd rather have today's tech. But I'm glad that I got to spend a lot of time with a C-64 in my youth, or I'd be nowhere near the programmer I am today. That's where the nostalgia comes in. Greatness in (relative) simplicity.
I wouldn't make a comment at all on this. But I will. I also hate the term tolerance, and prefer "acceptance". Tolerance means you hate something, but you deal with it anyway. I don't tolerate tolerance.
So there you go.
...we're another step closer to the reboot of Starlost...
I agree. There's no CNN, no Fox News, no MSNBC, no 24 hour live news at all.
It's absolutely FANTASTIC!
Your boss is making a financial argument for outsourcing. The only way to counter this, if you want to counter it, is with another financial argument against outsourcing. Despite the great many technical reasons not to outsource (and a few possible reasons in favor, perhaps), the decision that was made was a financial one. So if you want to argue against is, you need to be arguing in the same domain.
Here's my financial argument in favor of not outsourcing.
When you outsourcing, you are paying an external company to grow the necessary knowledge, skills, and ability to ship a software product. You are accruing zero of these assets to your company. When you have completed the project, you have generated one tangible asset, and zero intangible assets. All of the intangible assets are now owned by the party that you used to create the product. Furthermore, you have increased the value of the vendor, and thus you have increased the rate which that company can charge. And you can bet that this will be passed on to you in future product negotiations.
Inversely, with an in-house staff, the so called "extra cost" of staffing and benefits, if your environment is healthy enough to lead to employee retention of a reasonable level, leads to the accrual of in house knowledge on a wide range of topics. These include, but are not limited to: software development methodologies, planning, user interface design, software quality assurance, scheduling, testing, source code control, building reusable components, and many more. As the team matures, future products cost less.
So, in economic terms, you can outsource and pay a vendor less for the current project, adding value to that vendor. This will result either in escalating costs over time with the same vendor, or the continued use of a new vendor, and each new product will bear the cost of being a version 1 product with no institutional knowledge or economies of scale. Or you can keep things in house, pay more up front as the team develops the initial products, but with proper management you'll have a team that will produce products faster, with more personal investment, and higher quality, with a much smaller incremental cost over time.
I'd suggest "MTTD" and "AQ"
Mean TIme to Douchebaggery : Have your boss recruit some internal people to call your department with simple but real problems, and act like users who don't know anything. Record how long it takes the customer support rep to start acting like a complete douchebag. Longer times are better.
A-hole Ratio: As the manager, you should really know who the biggest a-holes on your team are. Determine if that's having a negative impact on other members of your team. Calculate the a-hole benefit (Tickets Closed) vs. perceived a-hole cost (lost productivity in tickets).
Both of these have a direct impact on your department's productivity. If people are individually productive but bad for business as a whole, get rid of them. But if they are "that good", maybe you need people who can better work with these a-holes.
Can they be gamed? Sure, by being less of a douchebag, or less of an a-hole. Sounds like a win-win.
Yes, I'm being flip. And yet, not really.
Even CoreAnimation is not beyond the "copying" argument. Microsoft shipped DirectAnimation years ago. Here's a link to the press release.
But this entire argument is completely useless. There are a number of skills at play when it comes to building and shipping any techology. First, a company needs to see an opportunity. Then, they need to design the right product for the market. Then they need to implement the product so that it can be easily used and make sure it's flexible enough that users can mould it into their products. Finally, the technology must be correclty marketed.
Fail at any of these, and you'll end up with a technological dead end. But that doesn't mean that somebody else didn't see the need as well, or that somebody else might not implement a better framework. That's supposed to be the beauty of our industry. There is room for competition and innovation, and no two products will hit the exact same sweet spot with a user base.
It doesn't matter who did it first. It matters who does it best for you. If I'm forced to code only on Linux, then I can tell you that CoreAnimation is not the technology for me. So I'll be looking for some competition. If I get to use OS X, I'm sure CoreAnimaiton will be useful. And if I'm on Windows, welll, DirectAnimation is dead. So I guess I'm screwed.
I don't care who was first, or who copied who. I need techology, and the capabilites of any library or feature I can use are highly dependent on the capabilities of the platform itself. If my OS provider can keep rolling out new features that help me write better software, I'm all for it. Even if they are copying somebody else. Where would any art form we have today be without the copying of features? Music, painting, storytelling; all art relies on a shared context. Great art works from there and pushes the boundaries. And I believe that coding can be an artistic expression. So I expect great programmers to borrow from each other, and then push those ideas in new directions.
We can argue which company's new direction we like best. But who is copying who? I don't care. I only care who is making the technology that I can use to write my software.
Ah, so this is the latest in Grim's Fairy Tales... Oh, wait, sorry, he's short an 'm'.
tags. Sigh.
Like most arguments, the real answer lies somewhere in the middle and changes drastically depending on context. I have worked on projects where there was far too much up-front planning, and on projects where there was nowhere near enough. I've seen agile methods thrive and fail, and I've seen waterfall thrive and fail. There is no single methodology that maximizes the possibility for success. What will work for your project depends on the scope of the project, the needs of the customer, and the team involved in the development. And, of those, I'd say the biggest factor is the knowledge and skill of the team. Not just in coding, but in understanding the project space and having a background in what has and hasn't worked in analogous conditions. One key element is having a technical decision maker who is also a good leader. This person must be able to analyze the current situation and always be working to advance progress. There are always conflicts in a major project, and having a single decision point (or a highly functional group of such people) is fundamental to success. If you decide to use a front-loaded design process, you need somebody who can reign in the scope of the project. They must be able to figure out when it is time to start documenting and planning and begin the work. I once interned at a bank, and watched a team do four months of eight hour per day meetings to plan a new system. They were still doing it a year later. The goal of a front loaded process is to establish a solid framework for the project, but if it never gets started, it's a waste of time. Similarly, agile methods fail if you don't know what you are working towards. That's why the decent Agile books all spend a lot of time on user stories, use cases, and planning short term goals. You buy in at the beginning to spending a lot of time refactoring code. Which is an easier sell to management than saying "We're going to write a lot of code, and then rewrite it constantly, even when it works." Both work, and both can fail miserably. It's the requirements of the project and the team that indicate which you use. If I'm working in an area where code audits are likely and I'm dealing with regulatory oversight, I'm front-loading the design. I want as many i's dotted and t's crossed up front, if only to legally cover myself and the bill-payers. And if I'm putting together a web site that I want to evolve over time, I'm going Agile. But in either case, I'm using as many techniques as I can from any style that helps. Agile style unit testing writen by the dev team instead of the testers at a bank? You bet. Sending my developers out to view the end users to do a process analysis before beginning an Agile project? Hell yes. Continuous integration? Always. The key is flexibility. Observe the team and the software. Watch what is working and what doesn't. And continuously feed that information back into the process to improve it. Good software is written by highly technical people who have the ability to communicate, led by a decisive and intelligent person who can comprehend and mesh the personal and business needs of the team, the users, and the project. No matter how much up-front work you do, you can never capture the entirely of the project. You must be flexible. Good software is never an academic exercise. It's an organic process. Like all processes, you can control the reaction with the right inputs and environment. When we reach the day that I can write a spec and hand it to two teams of developers and receive exactly the same code from both teams, I will leave the industry and never code again.
Oh, wait, there they are knocking on the door now. Guess I don't need the government search site after all.
The language you choose to learn is irrelevant. Like many fields of knowledge, the most important thing you can do is create a mental model of a computer that allows you to deduce more information.
So don't think in terms of a language. Pick a language to learn, but then try to understand what that language is actually doing. If you break down the standard C "Hello World" program, for example, you'll have tons to digest. When I define a string, what does the compiler do with it? How does it get passed to the printf funciton? What is a pointer? How does the compiler take my text and turn that into executable code? If you pick another language, you'll still have many of the same quesitons. The language is irrelevant.
So pick a task that you are passionate about. Pick a language that sounds interesting to you. And then start trying to solve the problem. And when you find that your mental model is insufficient, extend the model so it maps to your new knowledge. When you decide to learn a new language later on, odds are that 80% of your model will still apply.
I've seen a lot of people who learn C, and then move to another language and can't figure out why they don't need to end lines with semicolons. Or they don't understand how Java can do without pointers when they always needed them in C for structure arguments. The problem is not that they are stupid, it is that they don't really understand what is actually happening in the system as they code. Think about this from day one, and you'll have a much easier time of it.
And I'm not suggesting that you understand every nuance of the system. Odds are you be worrying about caching characteristics or interrupt timing for your first 50 or so projects. Many professional developers are clueless about the real hard-core system details. But the succesful ones all have a sufficient mental model for the level of work they do. And that's how they can adapt to changes in technology, languages and all things programming related.
Because, of course, all FUD is liberal. Calling something "liberal" doesn't make any points for you, it just makes your argument partisan. And that takes away any power you might have had to change the minds of "liberals" who might read it, no matter how good your data may be. If you want to convince a liberal they are wrong, don't call them a communist. If you want to convince a conservative they are wrong, don't call them jack-booted thugs. Just make your point, and if there is intelligence there, it might stick. Otherwise, you're just wasting bandwidth.
So far we have hundreds of comments criticizing the content of a series that is not even being written yet, based on what appears to be a poorly written web article that summarizes an interview that most of us have probably never heard. Let's hold off on destroying Lucas and the series producers until they actual give us something to destroy.
What I learned from this article is that while most people (including myself) do not like what Lucas did with Episodes 1-3, there is still a lot of excitement, or at least fan energy, in this franchise. Which makes it ripe for a TV series, wouldn't you think?
Enterprise did not ruin the Star Trek franchise. Bad writing, a failure to create compelling plot lines, and a complete lack of vision ruined the Star Trek franchise. If this show has a good team with a vision and the ability to execute, the show will be good. Sure, we'll all argue whether it's "The One True Star Wars" or not, but if it's compelling, people will watch. All the "Star Wars" brand gives them is a built in larger starting audience, more hype, and a huge set of expectations to live up to.
I've got an iBook, and there's no way I'm upgrading to this rev of the MacBook Pro. Have you felt the heat that comes off the bottom of those things? I checked out all the floor models in the local Apple Store, and every one of them was almost too hot to hold on to for more than a few seconds. The extra horsepower and promise of decent Windows perf under a new VPC in the future sound good, but that needs to be offset by the blistering of ones thighs.
The reason for a Halo2 port seems obvous: The goal is to sell more Xbox 360's. So far, there is no killer app for the console. Halo 3 is the obvious current front-runner. But only gamers who own an Xbox or with friends who own an Xbox have been able to play Halo 2. So the excitement is curently limited to customers who are already fans of the Xbox. If Halo 2 is available for the PC, however, then the audience for the game opens up. If the PC version is done well, it can drive more people to the franchise. Which means that the number of people who anticipate Halo 3 increeases, the buzz increases, and hopefully more hype means both more console and title sales and the stealing of PS3's thunder. The timing of hiring developers now, however, makes me question when they would expect to ship Halo 2 PC. If Halo 3 is coming out 'the day PS3 ships', then I doubt the port will be ready to ship before Halo 3. So I'm suprised they are hiring people this late. I think a Halo 2 port to the PC is a no brainer. So is selling it at a loss-leader price, like $30, to increase sales and therefore the potential Xbox purchaser market. But the timing, that's throwing me a bit. i'd expect this to be almost ready to ship by now. That would the product to hit the shelves a month or two before Halo 3, and work the buzz. Unless MS knows something about PS3 that we don't.