I am going to assume you have no experience in development by this theory. Well let me tell you why what you’re suggesting would not work.
In order to add / change code on a project you need to understand that project. Failing that whatever you do is likely to break a million things you didnt know depended on something you changed. That’s not a couple lines of code, its generally millions of lines. That getting familiar with a project generally takes 6 months – 1 year just to get to a point where you start being productive. Its much worst when you get no proper handover.
That alone is a bad idea for NCSoft cause lets assume they force Anet developers to switch over for a couple of years, they’re only going to take 1 year of actual production value and loose 2 years minimum (1 year for the anet developer to get up to speed + 1 year for the new developer coming in to replace the anet developer after they go back)
Also Anet is in Washington area, Carbine is in California so okey Ncsoft is going to ask a bunch of Anet developers to go work for carbine for a while … well that means spending a ton of money to move those devs to california only to move them back when the time comes.
But perhaps the biggest reason why NCsoft would never even consider such a move has got to be what they understand best… MONEY. Such a move would cost them colossal amounts of money.
1. Employee + family relocation – TWICE
2. 2 years of downtime on wildstar development that really can be cut in 1/2 if you hire new full time staff.
3. damaging your 2nd most profitable product in lieu of a product that’s unfortunately 2nd worst product and thats the quarter after release. why would they do that? there is no guarantee the problem with wildstar is one of development and even if that can be fixed its by a team you’re going to loose what if the one that comes after isnt going to be able to deliver either?Sorry to burst your bubble of convince but I do in fact have an idea of development. And moving onto new project is not really that hard when you are seasoned developer. 6 months is more than enough, that’s not some NASA spaceship…
Aside GW2 has been out for 2+ years.
And of course you missed the part where I mentioned the possibility of work from distance.
Do you know how many big game companies outsource work to 3rd parties? Mostly assets, not code, but there are devs who do that and it’s not hard.
There’s nothing new.Here’s an example for you
http://www.liquiddevelopment.com/about.phpedit: and btw GW2 as a product is beyond damaged already. Wonder why…
The example you gave relates to art work not coding. I doubt the Issue that made wildstar less then successful had to do with its art style. Thats probably one of its strong points.
Also probably its quicker to start working on a nasa spaceship then it is to start working on an MMO actually. Coding for Aerospace applications needs to be compact and simple as much as possible. The important part there is robustness not complexity. Bet that most MMOs have more lines of code then anything nasa have ever produce. Of course you need to be a lot more skilled to work on space stuff simply because to reduce that complexity everything needs to be designed from scratch. There is no using off the shelf libraries to cut down development time like an MMO can do. So obviously you need much more skilled developers to work on something like the space shuttle then you would an MMO but there will be ton less code to deal with.
http://en.wikipedia.org/wiki/Space_Shuttle
" the number of code lines was tiny compared to a public commercial software product, changes were only made infrequently and with extensive testing, and many programming and test personnel worked on the small amount of computer code"
and finally I didnt ignore your working remotely suggestion its just not really practical to have 100s of people working independently on something this complex. There needs to be a lot of co-ordination. There is a reason why a lot of MMOs adopt Agile development methodologies and one of the core aspects of Agile development is daily status meetings.