Different development teams with different interests... At the size of Microsoft, its not uncommon to end up an hydra with 2 heads. Though IE's crappiness ends up helping Silverlight indirectly, since quite a few developers will move to that to avoid having to deal with IE's quirks...
I'll be 100% honesty and say that I was never interviewed by Google myself, but my girlfriend did relatively recently and I got a fairly detailed description of how it went, and was able to match the OP's description on top of it, thus my above conclusion, so take what I say with a grain of salt, but...
from what Im seeing, the interviewer was doing exactly what they should have: put the person being interviewed in an unexpected challenge situation. Its more or less impossible to answer "correctly" a question from a google interview. They'll do and ask anything it takes to mess you up and throw you off balance, just to see how you react. The person who described their experience above seemed like they somewhat knew what they were saying (at least, the school-taught part of it), and the interviewer made things super precise until they didn't know what to answer anymore.
If the person had known these answers right off the bat too, they would have pushed further. All of it was probably just to seehow they'd react.
As a contractual developer, I've been to more interviews than I can count (douzans upon douzans upon douzans), and have myself passed people under interview. The challenges developers face are when they hit the unknown. No one gives a darn how you react to questions you know the answer of, or that are clear. In the real world, you'll have to deal with customers, clueless business analysts, buggy software, uncontrolable situations, and some that simply don't make sense. The way people handle these situations will dictate if they can shine or not, in that real world, especially a higher end environment like at Google. So again, from my point of view, the interviewer was quite clever. Maybe a bit too much:)
Of course, can't tell for sure without actually being there...
Re:Here's my inside scoop at a google interview
on
Want To Work At Google?
·
· Score: 4, Insightful
Actually, it seems obvious to me what the guy that interviewed you wanted to know: if you could convert what you learned in school in the real world. "Worse case scenario" (aka: O) isn't something you can blindly follow, as in many, many cases its irrelevent (thus why the 2 others). I can't talk for them, but in the place of a google engineer, I'd be MUCH more interested in "the most likely scenario" than in the worse case, since when you deal with a large amount of customers, the only thing that really matters is what happens day to day, and if the "worse case" happens, you add an extra server, be it at google, be it at your average corporation (not that simple, but you get the idea)
On top of that, google interviews are fairly known for seeing how you -react- to challenges, not your answers to them, thus the open ended questions. You could have answered all the questions wrong and they would take you anyway, if you showed your only weakness was experience, but they probably have seen too many people worrie about which sorting algorythm is the best when having to sort a 10 item dropdown menu...
Oh well, I'm sure your skillset will be more appreciated elsewhere, so no big loss to you:)
Microsoft stopped losing money on their consoles semi-recently, and now make a slight profit, as far as I know. Well, on a unit per unit basis anyway, because as a whole they're still in the red.
The only difference between Vista and XP's situation is that XP has been around for so long, people got used to it. My 1 year old lap-top back when XP came out was at the minimum requirements, yes, but -barely-.
My 4 years old lap-top of today could run Vista Premium peachy, except it has a DX8 videocard, and I don't -think- thats supported. if it is, it can run it fine by the specs.
My 3 years old PC runs it easily.
XP's been out for so long that people seem to have completly forgotten about XP's launch, and people got used to running a 5 years old OS on a modern machine, so when they see a new one, they go::gulp!::.
Indeed, totally true. And honestly, its nothing new. When Win2k and WinXP came out, I was still in college working part time supporting students with their computers. Even though Windows ME (yes, the one that we refuse to admit existed) was (and still is) the single worse OS of all time, people insisted on it and refused to upgrade, because its so much faster.
Even -today- I still know people who have shiney brand new WinXP CDs that they won't use, prefering 98 or ME with all their problem (and mostly unsupported!) because its faster on crap hardware (computers that could easily run most anything with XP, too).
Its nothing new really. The only difference is that XP stayed around much, MUCH longer than all its predecessors, so people got used to it. Hell, a lot of software developers now aren't even familiar with the process of checking their apps for compatibility with a newer version of Windows. That used to be the norm...
From my experience, companies do pay. A lot. With advantages. The catch is really "finding americans with the background".
What these companies want isn't someone who can code in assembly or deal with state machines. They want analysts, software architects, software engineers, developers, etc. In the current market, these are -rare-. I'm currently "only" a software developer with a bit of business analysis and software architecture background, and I have a -back log- of offers (that is, I'm on medium term contracts bouncing from jobs to jobs, with companies willing to wait 6+ months for me to finish a contract for the hope of an interview, at just about any rate I'm going to ask).
The sad part, si that I don't even have a BS, else it would be even more so. And most everyone i know with similar skillsets (and thats a lot, spawning both Canada and the US, as I travel a lot) are in the same situation.
Part of IT is in -extremely- high demand. Its just not the part where people hack code in Emacs. If you have the right skills, employers will kiss your boots.
#1 is fairly silly to compare this case against, since anyone can go and read the code of the higher level stuff in.NET. The patent is, I'm fairly sure, hitting at Datasets in.NET and their derivative (like XmlDataDocument). I've looked through that code quite a few times. Reviewed it 10 times over.
Or is this like if we considered Windows XP was the only revenue source of Microsoft during those years? And there I thought Microsoft had quite a few products (even if you don't count the "at a loss" ones).
Don't worrie, I am well aware of corporate software development. I am one of the primary developer for one of the largests non-software companies in the world:) We also have an army of DBAs and database-specific developers, and right now since it IS a stored-procedure-only environment, we have (just on the part I work with) several -douzans of thousands- stored procedure, that do everything you can imagine (including non-database related tasks). I've seen, or at least heard, most everything they can do, no worries:)
Optional parameters and parametrised order bys are the least of my worries here (though having a stored procedure with a dynamic amount of fields, multi-dimentational arrays of parameters, and dynamic order by clauses that allow to sort by a varying amount of fields end up being quite long to make, no matter the magic you apply to them. Easy to write, don't get me wrong, but...). And even with all that, I could just use, for example (on SQL Server), a CLR stored procedure, and even those problems would go away. Thats not the issue at hand.
The issue is that with a well thought out abstraction layer and automated scripts on top of the less critical parts of the applications, you can decouple your model and your database in ways that even a full layer (or two) of views and stored procedures simply can't do.
I mean, great: today my data is coming from 6 datacenters, using several different RDBMS, 2 different ETL technologies, and (thank god) only 1 OLAP system. Thats cute. If tomorrow I decide to change something in there....well, stored procedures aren't the most abstracted thing in the whole wide world. If I upgrade, let say, a SQL Server 2000 to 2005, well, the way to handle something as silly as filtering/paging efficiently changed. Now I have to go through the 4 thousand SPs that used the SQL Server 2k crippled way and optimise them? Hell no, that will probably be simply forgotten and never done. If it ain't broken don't fix it. If I have an SQL abstraction layer, I'll just change 2-3 functions, pass them through the unit and integration tests, and if everything comes up green the douzans of apps in my company will all take advantage of it by the next day.
On top of that, there's the notion that some things are simply easier to think of in an object oriented way, and it just feels real, REAL dumb to have 4 stored procedure for every god damn definition table (thousands!) in there. 90% of those won't be holding money amounts nor credit card numbers, and will be hiding behind locked down web services or remoting APIs -anyway-, so its not like anyone is getting direct access to the tables either. And if thats troublesome anyway (because of the risk of failure of these layers), you still have your views. And if thats still not enough, THEN of course (like in the example you gave), you go the stored procedure way, in which case the SP ends up being just an alternate datasource, the same way my ETLs and OLAP providers are. No biggy: even.NET's silly typed dataset allows you to switch between inline SQL and stored procedures completly transparently (though using inline SQL in a.NET dataset is unmaintainable, so thats probably a bad example:) )
What I'm getting at, is that (again, as your example shows), in corporate environments, doing without stored procedure is virtually impossible. No argument there! You -need- them. However, using ONLY stored procedures is simply a disaster waiting to happen, on top of being a hell of a waste of man hours. Some stuff is simply 10x faster to do using a well made SQL abstraction API. The important part is to always have a good way of using the stored procs that will come in.
I would fire that guy in no time too. However, I'd probably fire YOU too. If you think the only way around stored procedures is "messy inline SQL", you haven't done anything beyond trivial, OR you worked for a large corporation where the software architects haven't looked anywhere beyond what they originally learned in over a decade.
there are douzans of ways to use dynamic SQL in maintainable, efficient ways. Stored procedures have quite a few advantages that can't be brushed off either, so it really comes to the people in charge to make an enlightened decision, but its NOT as simple as "SP good, everything else bad!". Both sides of the spectrums have their good points, and everywhere in between (a mix of both methods).
Slightly different if the guy is in his car quite a bit away from home parked near a house... "Sorry sir, I was driving, when my lap-top turned itself on, connected, and made me watch all that free porn. I couldn't help it! it made me do it!!"
Correct. The way to promote women going to CS programs is to enhance the social activities revolving around it, or hell, anything you want around it, but not the classes themselves. Thats just hurting everyone.
The problem, having worked for a time as customer support for an extremely large company, is simply how many people actually DO lie. It is excessively rare (relatively speaking) that a customer, in most fields, has a problem and its not their fault. Think retail: how many people will try to trade in something they broke? Think an ISP: How many people will claim their internet service is down, when they actually screwed up their PCs? By far, far, the majority. From my experience, its pushing 10 to 1.
So unfortunately, unless you want your company to go bankrupt, you can't take what the customer say at face value: they will, and DO abuse it. But at the same time, if you screw over too many innocents, you will go out of business too... so its a matter of finding a balance, unfortunately.
Normally, something like a mainstream 4GL programmer (like VB6, though I can't think of any that are quite mainstream anymore) is pain less than a.NET programmer, who's pain (slightly) less than a Java programmer, who's pain less than a C++ programmer, who's paid less than an assembly programmer.
Or something. Just a matter of supply and demand. Demand for C++ programmers ain't so hot anymore, but supply is extremely low, with the only place really to get them is straight out of college, since otherwise right after they'll flush all their C/C++ experience for one of the newer environments.
Not really hard data to back this fact, just my observations from last time I was looking for a job (a few months ago), so take that with a grain of salt, but...
Indeed. I never got that really. I understand Microsoft's total domination in other markets: making a Direct X game is so much easier than open GL. C# and especially VB.NET are an order of magnitude easier to learn than alternatives. SQL Server (not really dominating, but has a subtential market share in OLAP and such) is fully GUI based, and has the easiest OLAP and ETL systems to use that I've ever heard of.
Then you have Internet Explorer. Coding "IE-only" is harder, by far, than coding crossbrowser Firefox/Opera, by a factor of 10 (you can add Safari to the mix if you don't try to do anything too fancy in javascript, where a few bugs and weird behaviors start showing). As soon as IE's market share goes low enough, you'll see "W3C compliant only" sites popping up fast enough. I'm impressed the revolt didn't happen sooner: for many other microsoft product, when something screws up on the developer site, you see hundreds of posts piling up on MS blogs...
Nope, so really its only to stop a big company from buying 10000 license of home basic to run something with virtualization (macs have nothing to do with it, the "rule" applies even if you run it on top of another windows install...)
Agreed. I'll actually say that, with a realistic implementation of CSS that reflects today's needs (web APPLICATION, not just web PAGES), XHTML 1 would be okay... In the end, the important part is being able to use a standard XML parser to parse validated markup, instead of "tag soup parsers".
Once we can do that, we're good to go. The rest is just icing on the cake.
Funny enough, the upgrade of Frontpage (Microsoft Expression Web) actualy renders (in its wysiwyg) html and css quite correctly. So its always amusing to do some more advanced CSS (mind you, advanced from IE's point of view. We're talking basic stuff like min-width or display:table-*) and have it work perfectly in Expression Web, then opening it in Opera or Firefox, and have it work exactly (or well, as exactly as wysiwyg will work). Then opening it in IE (especially 6, obviously) and it breaks horribly.
This is really a place where Microsoft is a 2 headed entity. The web development team(s) (asp.net, their ajax team, microsoft expression, the next version of visual studio, etc) tend to, for the most part (at least recently) work toward standards, cross browser stuff, etc. The browser team though... I guess they're doing their best while being whipped by the people who sign their paychecks.
Thats probably why PC gaming is slowing down a lot more than because of MMOs... between games like Oblivion and Neverwinter Nights 2...these games were released in a state that could barely be qualified as alpha by console standards. I am and always was a PC game fan, but this is getting out of hands.
Indeed. Hell, we see it all the time, being able to PATCH a software just means that it will be buggier on release, and never really get better than the unpatchable version... Thats whats semi-killed off PC gaming, since console games have always been released with less bugs than PC games have after the first 5 patches... though with consoles with harddrives and such, that might be history in a few years...
Slashdot Mirror
Better shoot for .NET 3.5 right away, otherwise by the time you're done, you'll be a full version behind...
Different development teams with different interests... At the size of Microsoft, its not uncommon to end up an hydra with 2 heads. Though IE's crappiness ends up helping Silverlight indirectly, since quite a few developers will move to that to avoid having to deal with IE's quirks...
I'll be 100% honesty and say that I was never interviewed by Google myself, but my girlfriend did relatively recently and I got a fairly detailed description of how it went, and was able to match the OP's description on top of it, thus my above conclusion, so take what I say with a grain of salt, but...
:)
from what Im seeing, the interviewer was doing exactly what they should have: put the person being interviewed in an unexpected challenge situation. Its more or less impossible to answer "correctly" a question from a google interview. They'll do and ask anything it takes to mess you up and throw you off balance, just to see how you react. The person who described their experience above seemed like they somewhat knew what they were saying (at least, the school-taught part of it), and the interviewer made things super precise until they didn't know what to answer anymore.
If the person had known these answers right off the bat too, they would have pushed further. All of it was probably just to seehow they'd react.
As a contractual developer, I've been to more interviews than I can count (douzans upon douzans upon douzans), and have myself passed people under interview. The challenges developers face are when they hit the unknown. No one gives a darn how you react to questions you know the answer of, or that are clear. In the real world, you'll have to deal with customers, clueless business analysts, buggy software, uncontrolable situations, and some that simply don't make sense. The way people handle these situations will dictate if they can shine or not, in that real world, especially a higher end environment like at Google. So again, from my point of view, the interviewer was quite clever. Maybe a bit too much
Of course, can't tell for sure without actually being there...
Actually, it seems obvious to me what the guy that interviewed you wanted to know: if you could convert what you learned in school in the real world. "Worse case scenario" (aka: O) isn't something you can blindly follow, as in many, many cases its irrelevent (thus why the 2 others). I can't talk for them, but in the place of a google engineer, I'd be MUCH more interested in "the most likely scenario" than in the worse case, since when you deal with a large amount of customers, the only thing that really matters is what happens day to day, and if the "worse case" happens, you add an extra server, be it at google, be it at your average corporation (not that simple, but you get the idea)
:)
On top of that, google interviews are fairly known for seeing how you -react- to challenges, not your answers to them, thus the open ended questions. You could have answered all the questions wrong and they would take you anyway, if you showed your only weakness was experience, but they probably have seen too many people worrie about which sorting algorythm is the best when having to sort a 10 item dropdown menu...
Oh well, I'm sure your skillset will be more appreciated elsewhere, so no big loss to you
Microsoft stopped losing money on their consoles semi-recently, and now make a slight profit, as far as I know. Well, on a unit per unit basis anyway, because as a whole they're still in the red.
Simple, and anyone can understand it this way: The internet is what you get when you put as much porn as possible in one easy to access package.
The only difference between Vista and XP's situation is that XP has been around for so long, people got used to it. My 1 year old lap-top back when XP came out was at the minimum requirements, yes, but -barely-.
::gulp!::.
My 4 years old lap-top of today could run Vista Premium peachy, except it has a DX8 videocard, and I don't -think- thats supported. if it is, it can run it fine by the specs.
My 3 years old PC runs it easily.
XP's been out for so long that people seem to have completly forgotten about XP's launch, and people got used to running a 5 years old OS on a modern machine, so when they see a new one, they go
Indeed, totally true. And honestly, its nothing new. When Win2k and WinXP came out, I was still in college working part time supporting students with their computers. Even though Windows ME (yes, the one that we refuse to admit existed) was (and still is) the single worse OS of all time, people insisted on it and refused to upgrade, because its so much faster.
Even -today- I still know people who have shiney brand new WinXP CDs that they won't use, prefering 98 or ME with all their problem (and mostly unsupported!) because its faster on crap hardware (computers that could easily run most anything with XP, too).
Its nothing new really. The only difference is that XP stayed around much, MUCH longer than all its predecessors, so people got used to it. Hell, a lot of software developers now aren't even familiar with the process of checking their apps for compatibility with a newer version of Windows. That used to be the norm...
From my experience, companies do pay. A lot. With advantages. The catch is really "finding americans with the background".
What these companies want isn't someone who can code in assembly or deal with state machines. They want analysts, software architects, software engineers, developers, etc. In the current market, these are -rare-. I'm currently "only" a software developer with a bit of business analysis and software architecture background, and I have a -back log- of offers (that is, I'm on medium term contracts bouncing from jobs to jobs, with companies willing to wait 6+ months for me to finish a contract for the hope of an interview, at just about any rate I'm going to ask).
The sad part, si that I don't even have a BS, else it would be even more so. And most everyone i know with similar skillsets (and thats a lot, spawning both Canada and the US, as I travel a lot) are in the same situation.
Part of IT is in -extremely- high demand. Its just not the part where people hack code in Emacs. If you have the right skills, employers will kiss your boots.
From the wording "making a component with XML used in web application", it sounds more like datasets. Which Mono has.
#1 is fairly silly to compare this case against, since anyone can go and read the code of the higher level stuff in .NET. The patent is, I'm fairly sure, hitting at Datasets in .NET and their derivative (like XmlDataDocument). I've looked through that code quite a few times. Reviewed it 10 times over.
Or is this like if we considered Windows XP was the only revenue source of Microsoft during those years? And there I thought Microsoft had quite a few products (even if you don't count the "at a loss" ones).
Don't worrie, I am well aware of corporate software development. I am one of the primary developer for one of the largests non-software companies in the world :) We also have an army of DBAs and database-specific developers, and right now since it IS a stored-procedure-only environment, we have (just on the part I work with) several -douzans of thousands- stored procedure, that do everything you can imagine (including non-database related tasks). I've seen, or at least heard, most everything they can do, no worries :)
.NET's silly typed dataset allows you to switch between inline SQL and stored procedures completly transparently (though using inline SQL in a .NET dataset is unmaintainable, so thats probably a bad example :) )
Optional parameters and parametrised order bys are the least of my worries here (though having a stored procedure with a dynamic amount of fields, multi-dimentational arrays of parameters, and dynamic order by clauses that allow to sort by a varying amount of fields end up being quite long to make, no matter the magic you apply to them. Easy to write, don't get me wrong, but...). And even with all that, I could just use, for example (on SQL Server), a CLR stored procedure, and even those problems would go away. Thats not the issue at hand.
The issue is that with a well thought out abstraction layer and automated scripts on top of the less critical parts of the applications, you can decouple your model and your database in ways that even a full layer (or two) of views and stored procedures simply can't do.
I mean, great: today my data is coming from 6 datacenters, using several different RDBMS, 2 different ETL technologies, and (thank god) only 1 OLAP system. Thats cute. If tomorrow I decide to change something in there....well, stored procedures aren't the most abstracted thing in the whole wide world. If I upgrade, let say, a SQL Server 2000 to 2005, well, the way to handle something as silly as filtering/paging efficiently changed. Now I have to go through the 4 thousand SPs that used the SQL Server 2k crippled way and optimise them? Hell no, that will probably be simply forgotten and never done. If it ain't broken don't fix it. If I have an SQL abstraction layer, I'll just change 2-3 functions, pass them through the unit and integration tests, and if everything comes up green the douzans of apps in my company will all take advantage of it by the next day.
On top of that, there's the notion that some things are simply easier to think of in an object oriented way, and it just feels real, REAL dumb to have 4 stored procedure for every god damn definition table (thousands!) in there. 90% of those won't be holding money amounts nor credit card numbers, and will be hiding behind locked down web services or remoting APIs -anyway-, so its not like anyone is getting direct access to the tables either. And if thats troublesome anyway (because of the risk of failure of these layers), you still have your views. And if thats still not enough, THEN of course (like in the example you gave), you go the stored procedure way, in which case the SP ends up being just an alternate datasource, the same way my ETLs and OLAP providers are. No biggy: even
What I'm getting at, is that (again, as your example shows), in corporate environments, doing without stored procedure is virtually impossible. No argument there! You -need- them. However, using ONLY stored procedures is simply a disaster waiting to happen, on top of being a hell of a waste of man hours. Some stuff is simply 10x faster to do using a well made SQL abstraction API. The important part is to always have a good way of using the stored procs that will come in.
I would fire that guy in no time too. However, I'd probably fire YOU too. If you think the only way around stored procedures is "messy inline SQL", you haven't done anything beyond trivial, OR you worked for a large corporation where the software architects haven't looked anywhere beyond what they originally learned in over a decade.
there are douzans of ways to use dynamic SQL in maintainable, efficient ways. Stored procedures have quite a few advantages that can't be brushed off either, so it really comes to the people in charge to make an enlightened decision, but its NOT as simple as "SP good, everything else bad!". Both sides of the spectrums have their good points, and everywhere in between (a mix of both methods).
Slightly different if the guy is in his car quite a bit away from home parked near a house... "Sorry sir, I was driving, when my lap-top turned itself on, connected, and made me watch all that free porn. I couldn't help it! it made me do it!!"
Correct. The way to promote women going to CS programs is to enhance the social activities revolving around it, or hell, anything you want around it, but not the classes themselves. Thats just hurting everyone.
The problem, having worked for a time as customer support for an extremely large company, is simply how many people actually DO lie. It is excessively rare (relatively speaking) that a customer, in most fields, has a problem and its not their fault. Think retail: how many people will try to trade in something they broke? Think an ISP: How many people will claim their internet service is down, when they actually screwed up their PCs? By far, far, the majority. From my experience, its pushing 10 to 1.
So unfortunately, unless you want your company to go bankrupt, you can't take what the customer say at face value: they will, and DO abuse it. But at the same time, if you screw over too many innocents, you will go out of business too... so its a matter of finding a balance, unfortunately.
Hmm... now thats a nice freudian slip.
Normally, something like a mainstream 4GL programmer (like VB6, though I can't think of any that are quite mainstream anymore) is pain less than a .NET programmer, who's pain (slightly) less than a Java programmer, who's pain less than a C++ programmer, who's paid less than an assembly programmer.
Or something. Just a matter of supply and demand. Demand for C++ programmers ain't so hot anymore, but supply is extremely low, with the only place really to get them is straight out of college, since otherwise right after they'll flush all their C/C++ experience for one of the newer environments.
Not really hard data to back this fact, just my observations from last time I was looking for a job (a few months ago), so take that with a grain of salt, but...
Indeed. I never got that really. I understand Microsoft's total domination in other markets: making a Direct X game is so much easier than open GL. C# and especially VB.NET are an order of magnitude easier to learn than alternatives. SQL Server (not really dominating, but has a subtential market share in OLAP and such) is fully GUI based, and has the easiest OLAP and ETL systems to use that I've ever heard of.
Then you have Internet Explorer. Coding "IE-only" is harder, by far, than coding crossbrowser Firefox/Opera, by a factor of 10 (you can add Safari to the mix if you don't try to do anything too fancy in javascript, where a few bugs and weird behaviors start showing). As soon as IE's market share goes low enough, you'll see "W3C compliant only" sites popping up fast enough. I'm impressed the revolt didn't happen sooner: for many other microsoft product, when something screws up on the developer site, you see hundreds of posts piling up on MS blogs...
Nope, so really its only to stop a big company from buying 10000 license of home basic to run something with virtualization (macs have nothing to do with it, the "rule" applies even if you run it on top of another windows install...)
Agreed. I'll actually say that, with a realistic implementation of CSS that reflects today's needs (web APPLICATION, not just web PAGES), XHTML 1 would be okay... In the end, the important part is being able to use a standard XML parser to parse validated markup, instead of "tag soup parsers".
Once we can do that, we're good to go. The rest is just icing on the cake.
Funny enough, the upgrade of Frontpage (Microsoft Expression Web) actualy renders (in its wysiwyg) html and css quite correctly. So its always amusing to do some more advanced CSS (mind you, advanced from IE's point of view. We're talking basic stuff like min-width or display:table-*) and have it work perfectly in Expression Web, then opening it in Opera or Firefox, and have it work exactly (or well, as exactly as wysiwyg will work). Then opening it in IE (especially 6, obviously) and it breaks horribly.
This is really a place where Microsoft is a 2 headed entity. The web development team(s) (asp.net, their ajax team, microsoft expression, the next version of visual studio, etc) tend to, for the most part (at least recently) work toward standards, cross browser stuff, etc. The browser team though... I guess they're doing their best while being whipped by the people who sign their paychecks.
Thats probably why PC gaming is slowing down a lot more than because of MMOs... between games like Oblivion and Neverwinter Nights 2...these games were released in a state that could barely be qualified as alpha by console standards. I am and always was a PC game fan, but this is getting out of hands.
Indeed. Hell, we see it all the time, being able to PATCH a software just means that it will be buggier on release, and never really get better than the unpatchable version... Thats whats semi-killed off PC gaming, since console games have always been released with less bugs than PC games have after the first 5 patches... though with consoles with harddrives and such, that might be history in a few years...