The Hub of All Blame: A Postmortem

[MikeRozak]

9 years ago, when I worked for Microsoft, when dealing with a 3rd party software company (such as Sigil), Microsoft would use its testers for (a) compatability testing with video cards and whatnot, and (b) sanity checks that the 3rd party was doing testing. At the time (and more specifically in the group I was with) Microsoft testing would not be responsible for detailed testing of the 3rd party software. Thus, I suspect that Microsoft expected Sigil to do the bulk of their own testing (... but I haven't seen the contract).

As a general rule, you want one tester per developer, starting fairly early on.

As a matter of good practice, with 100 employees, Sigil should have had 100 DIFFERENT graphics cards on all sorts of differnt systems. This is for added compatability testing. Part of what Microsoft was offering was its compatability labs where they have 100-isdufferent sound cards.

In some of the groups I was in at Microsoft, we'd have "testing days" where everyone in the team became testers. These were very effective. It's a way of getting testing done despite there not being many testers.

I see the whole "getting passed onto zoo tycoon" as a sign that upper management wasn't happy with Vanguard.  (Someone posted that upper management isn't technical and just wants gantt charts... At Microsoft, upper management tends to be very technical.)

My guess is that the request for more-detailed milestone schedules would have come about because someone in microsoft said, "These guys aren't performing. We need to put them on a tighter leash." The zoo-tycoon manager may have been the leash. When the tighter leash failed, they canned the project.

[tentimes]

People can get very caught up in their own version of reality. I work with high risk offenders (I used to write code but I am now in the helping profession) What I find is that every high risk offender I work with (whether rapist, murderer or whatever else) has a very clear picture of themselves being a victim. It seems an absolute precursor to any crime. I have yet to meet a customer who doesn't feel he is a victim. In a way they are right, but in another very definite way it points out what is wrong.

When you look at what corporate society has become, Brad is a typical Sociopath Member of it. When I read this interview with him I was reminded of the kids I work with. To accept responsibility would just totally crush their whole self image - they can't do it, it would kill them. So they keep 'building' their image.

We are already creating a race of sociopaths in RL, do we need to let someone else away because he didnn't want to confront what happened and possibly 'cry' in front of his employees? Perhaps he would have needed to be a real person for that bit? The more I read it the more I think I need to trust my first judgement.

[Morat20]

At the "first annual XP Conference" in 2001, I managed to get most everyone but Kent Beck (so Ward Cunningham, who is great, Martin Fowler, who is a savant, and Ron Jeffries, who is very "GET OFF MY LAWN") that XP only worked in large-scale corporate environments if teams were allowed to modify or abandon any of the 12 rules that did not or could not apply to the situation.  Beck's response was a hard line "you have to make everyone do everything, or it isn't XP".  The word "Extreme" was also a barrier for us, as it flat out scared the crap out of management.

Anyways - to me, an "Agile" methodology comes from this way of thinking.  XP is a great theoretical idea, but is not practical in it's full incarnation.  But neither of them would preclude the ability to effectively communicate schedules, deadlines, shifts in scope, etc. 

My last class (a fucking boring class to boot) on project management had a professor who drove home -- ruthelessly and with rigid focus -- the notion that shit like Agile Programming, XP, iterative programming, waterfall models (ugh!) isn't a blueprint for success. They're more like rules of thumb. They're a starting point -- more like a freakin' business philosophy -- from which a competent manager begins. Everything is tailored for the project at hand.

80% of the reading for that course was, in effect, articles, papers and software processes that were variations from the template. Most of our work was in discussing what changes were necessary, how they affected the processes and final products, and how and when you identify what to jettison, what to keep, and what to modify to the task at hand.

It helped working out here in the real world -- I've seen about 5 variations of the same process in as many years (same company, same department, different projects -- we have a very skilled project manager) and each was custom tailored to the project, personnel, and needs of the project. Management -- for all the damn paperwork, Gannt charts, artifacts, milestones, and the like -- requires a great deal of inventiveness and flexibility coupled with discipline and a great deal of skill. One of the reasons I avoid it like the plague. :)

[Trippy]

At the "first annual XP Conference" in 2001, I managed to get most everyone but Kent Beck (so Ward Cunningham, who is great, Martin Fowler, who is a savant, and Ron Jeffries, who is very "GET OFF MY LAWN") that XP only worked in large-scale corporate environments if teams were allowed to modify or abandon any of the 12 rules that did not or could not apply to the situation.  Beck's response was a hard line "you have to make everyone do everything, or it isn't XP".  The word "Extreme" was also a barrier for us, as it flat out scared the crap out of management.

Anyways - to me, an "Agile" methodology comes from this way of thinking.  XP is a great theoretical idea, but is not practical in it's full incarnation.  But neither of them would preclude the ability to effectively communicate schedules, deadlines, shifts in scope, etc. 

Yes that's one of the criticisms of XP -- the practices are interdependent and it's very difficult to try and just adopt some of them to start even if you wanted to, it's kind of all or nothing. The Agile Manifesto is more general than XP and is a more useful starting point than XP for learning about agile methodologies.

[Sauced]

I'm fortunate enough at the moment to be peddling my agile beliefs at a company that was in a "mini-Chrysler" moment about 18 months ago - they were falling on their faces, and the leading trade rag put their technology dead last in the industry.  So they rebuilt their tech org from scratch, and we were essentially given free reign thanks to the new CTO who wanted an agile dev team.  In the time it would have taken to write all of the design docs for the first release, we had won several large clients for the company with our finished (heh) product.

I used to be fairly big on paired programming, but I'm more of a special case only kind of guy.  A consensus during task planning can get a Jira task marked as "pair on this plz", but it's rare (and our tasks are usually 2-6 hours if we're doing it right).

[Morat20]

Yes that's one of the criticisms of XP -- the practices are interdependent and it's very difficult to try and just adopt some of them to start even if you wanted to, it's kind of all or nothing. The Agile Manifesto is more general than XP and is a more useful starting point than XP for learning about agile methodologies.

I admit I'd like some experience with XP in a situation where it actually worked (the only time it's come up was in conjunction with something that Jesus himself could not have saved, much less a mere development process) but I have a hard time seeing it working large-scale, simply because no large scale project is built up of purely high-quality employees.

I've worked with several people who could probably do amazing shit in an XP enviroment, and just as many who would be aimless and lost (or at least need a ton of hand-holding). It's all well and good to want to staff your project with the cream of the crop -- I don't think it's feasible. I think working XP requires a level of skill and dedication that's rarely going to be achievable in larger projects.

In terms of communication -- that's more of a gut-feeling that XP in practice is going to cause problems along those lines, but that is probably just projection based off of my work enviroment and recent project history. If I were managing it from scratch, I'd still have concerns though. (Then again, if I was managing it -- I could make sure those concerns were addressed. So, a wash I suppose).

Sauced: Sounds like right man, right place. I had a much, much tinier moment like that about a year ago when I managed to pitch a machine learner to do insta sort-and-analyze of a reoccuring problem. Managed to scrape together a neural net that had about a 96% success rate (we were shooting for 90%) and sorts it out pretty much instantly. Was a hell of a lot of fun doing, too. DIdn't save the company -- or the project -- but it did knock off a really annoying problem. :)

[Margalis]

My guess is that the request for more-detailed milestone schedules would have come about because someone in microsoft said, "These guys aren't performing. We need to put them on a tighter leash." The zoo-tycoon manager may have been the leash. When the tighter leash failed, they canned the project.

My experience has always been that the people who are tracked very tightly against a schedule are the people not trusted to work without that tracking.

When people are not productive that is always the reponse - we need to break down the schedule into smaller pieces and track it much more finely. Which of course never works, but whatever.

Edit: Funny Slashdot post on the subject:

Sigil = Ion Storm
Vanguard = Daikatana
McQuaid = Romero
EQ1 = DOOM


Brad McQuaid is going to make you his bitch!

[Morat20]

My experience has always been that the people who are tracked very tightly against a schedule are the people not trusted to work without that tracking.

When people are not productive that is always the reponse - we need to break down the schedule into smaller pieces and track it much more finely. Which of course never works, but whatever.

If it's not working already, and you're not ready to pull the plug or fire the employee or the equivilant -- what else is there? You either fix the problem (replace the poorly performing employee, replace the bad process, etc) or you pull the plug and cancel the whole thing. Or I suppose you can send them time management classes, which seems to be the current brilliant idea floating around upper-upper management these days.

Of course, my own impending enrollment in one of those lovely time-wasters is due to the fact that someone up the chain, whom I seem perhaps once a year during Ye Olde Fashioned Employee Performance Review -- confused "difficulting properly estimating development time" with "poor time management skills". They are two distinct things, and not all the classes involving jars, big rocks, small rocks, and sand is going to make up for the fact that my customers love nothing more than to tag "And can you add..." to the end of a meeting, throwing my schedule into the shitter.

[Tale]

I don't blame Brad for maintaining some PR speak. If he is still associated with the project, he is not free to speak openly. And it is unprofessional to just dish the dirt from a high level, as opposed to the rank and file Sigil employee previously interviewed. That's the nature of these things. You see the same professional courtesy from Raph and most other people who have been a figurehead in game development controversies.

[Drogo]

Schild definitely did a great job on this one. It was nice to read about both sides in the Vanguard saga.

For the many people who think no one will ever give him 30 million dollars for a game again, I think you are dead wrong.

People like to give money to someone who has a proven track record for releasing games. Brad had one great game and one awful game release so far, but both of his games have been released. How many MMOs are aborted before they even make it to launch?

So in my opinion a company that wants to invest money to make an MMO is more likely to give money to Brad long before they give money to some unknown company with no track record. Investment companies are not going to scan the internet to find out how much people in EQ hated his Vision or how he did a terrible job as a CEO for Sigil. They are going to see someone that has started out to make two MMOs and launched two MMOs. Combine that with the comments about how he is good at making a sales pitch and how well he is at spinning things to show himself in a good light and it seems like Brad has a better shot at getting investment money than the majority of people currently in the MMO business if he should decide to go for a third release.

Now don't get me wrong, I think his next game will be just as bad as Vanguard unless he learns some valuable lessons. I just think he will get the money to make a third game if he really wants it.

I would bet that Brad will be posting about his next, next generation MMO within two years.

[Trippy]

Investment companies are not going to scan the internet to find out how much people in EQ hated his Vision or how he did a terrible job as a CEO for Sigil.

The good ones will (and they did when Brad went looking for VC money). The bad ones might not.

[Morat20]

Investment companies are not going to scan the internet to find out how much people in EQ hated his Vision or how he did a terrible job as a CEO for Sigil.

The good ones will (and they did when Brad went looking for VC money). The bad ones may not.

Did Vanguard raise any VC money, or was that all MS (and later SOE)? I wasn't really following it until around Vanguard's alpha, so my understanding of it's initial development is spotty.

Speaking of -- I bet the wikipedia entries for Brad, Sigil, and Vanguard are a fun battleground right now.

[Trippy]

Investment companies are not going to scan the internet to find out how much people in EQ hated his Vision or how he did a terrible job as a CEO for Sigil.

The good ones will (and they did when Brad went looking for VC money). The bad ones may not.

Did Vanguard raise any VC money, or was that all MS (and later SOE)? I wasn't really following it until around Vanguard's alpha, so my understanding of it's initial development is spotty.

I don't know if he managed to raise some VC money, though it's unlikely since that typically gets a PR release if it's above a trivial amount of money. I do know for a fact that he wasn't having much luck convincing some of the better-known San Francisco Bay Area VCs to fund him which is how I know they did do background checking on Vanguard and Sigil.

[Zodiac]

*resists urge to join in on the agile development debate*

Every company, every team's different. But repro steps for everyone:

1) Read and study many different processes and frameworks
2) Adopt what you can
3) Make lots of mistakes inevidently
4) Learn from them and refine your processes
5) Repeat steps 1-4
6) Profit

[Morat20]

*resists urge to join in on the agile development debate*

Every company, every team's different. But repro steps for everyone:

1) Read and study many different processes and frameworks
2) Adopt what you can
3) Make lots of mistakes inevidently
4) Learn from them and refine your processes
5) Repeat steps 1-4
6) Profit

Did you teach my class last semester? I'd have shown up to the face-to-face version! :)

Yar, that's pretty much the standard we got -- which fits nicely into my experiences. The class was real-world geared, not theory-oriented. About 2/3rds of the class was there out of the real world, and since discussion was a required element -- we spent a lot of time comparing and contrasting theory to practice.

It's dry stuff, and not any more interesting in practice. It is, however, really necessary.

[Llava]

I just want to chime in to let schild know he's doing the Lord's work.

[wraith808]

As a general rule, you want one tester per developer, starting fairly early on.

::blinks::  ::doubletake::

Say wha...?

I've *never* seen this in real life.  *Never*.  I've been in QA and development (and various other positions).  And ... *never*.  Especially dedicated testers...  As sorry as it is, testing, even on large projects, is generally a bastard child of the software process.

[bhodi]

What you want and what you get are two very different things.

[Trippy]

Speaking of -- I bet the wikipedia entries for Brad, Sigil, and Vanguard are a fun battleground right now.

LOL, somebody used the first interview as a reference in Wikipedia. f13 is authoritative!

[El Gallo]

A+ interview Schild, and some props to Brad for actually answering those questions.  Clearly he's in utter denial/shock right now.  If he can learn the needed lessons (1-understand what people actually liked and didn't like about his first game 2-learn how to manage a project that isn't you and your buds making something in the garage) he could make something good in the future.  Don't know that he ever will, though.  He and Koster are pretty similar in that respect imo.  

[Miasma]

I'm fortunate enough at the moment to be peddling my agile beliefs at a company that was in a "mini-Chrysler" moment about 18 months ago - they were falling on their faces, and the leading trade rag put their technology dead last in the industry.  So they rebuilt their tech org from scratch, and we were essentially given free reign thanks to the new CTO who wanted an agile dev team.  In the time it would have taken to write all of the design docs for the first release, we had won several large clients for the company with our finished (heh) product.

I used to be fairly big on paired programming, but I'm more of a special case only kind of guy.  A consensus during task planning can get a Jira task marked as "pair on this plz", but it's rare (and our tasks are usually 2-6 hours if we're doing it right).

Extreme programming eh?  Not many programming methodologies have entire books published warning about how bad they are.  The similarities between the C3 project and Vanguard are stunning.  Both were very late, both never worked properly, both had obscene system requirements due to sloppy code and both wound up being total failures.  Hell, at least Vanguard managed to ship and see the light of day, the C3 project never even got that far.  And even Brad didn't have the balls to write a book about how awesome his way of doing things is a year before his project failed like Beck did.  The C3 program took days to run and only managed to generate 10,000 out of the 90,000 paystubs it was supposed to create before completely exploding.

And your earlier "Rock Star" comment is pretty amazing considering the XP three absolutely think of themselves like that,  to the point of naming themselves the best developers on the face of the Earth.

Agile programming is fine but if you actually drink the EXTREME programming mountain dew (in its entirety) you're insane.

[DataGod]

Communication is always an important thing in any software project where the number of programmers is > 1 unless they are working on completely orthogonal systems and even then they should be talking to each other. There's nothing about XP or Agile that says you have to keep track of what everybody else is doing. Regular meetings is a part of Agile methodologies (e.g. Scrum has very short daily "standup" meetings) but again that doesn't mean everybody has to keep track of what everybody else is doing. Fred Brooks proved long ago that that sort of thing is what actually slows down software development rather than speeding it up.

I see what you mean. Even so, I think there's a natural team size that limits Agile or XP as an overall design methodology. But not for components -- Agile is an excellent way to develop subcomponents (or primary modules) of a large scale system. Care must be taken at interfaces, but there's absolutely nothing wrong (and a hell of a lot right) about using a very agile process down at the bottom where the real work is done.

And that applies to artists and designers as well as coders.

But you've got to have the large-scale processes -- specifically the management set -- to handle that for the project as a whole. One of the hardest problems I had with the whole "project management" concept was in trying to allow maximum flexibily for the individual aspects of a project, while keeping the bloody thing unified as a whole. Doing it with five people it's just a matter of keeping tabs on people -- doing it with 100, and I really need those papers, those Gannt charts, those milestones, those work breakdown structures.

Someone's got to be keeping a big enough eye on the picture to go down to the engine guys and tell them what they're doing is all awesome and shit, but the designers really need that upgraded toolset about two weeks ago and it's delaying the artists ability to do all the awesome stuff, and it's going to slip the whole bloody project so can they tweak the lighting code or whatever next week and please for the love of God get those tools done so the artist shut up and the money people stop screaming at me?

Modules should be loosely coupled, generally speaking. If a programmer A working on module A has to worry about the specific code programmer B is writing in module B then that's a sign those two modules are not perhaps as loosely coupled as they could be. Of course not all modules can be loosely coupled so this sort of thing doesn't always apply.

I'm more used to very large modules that often have highly coupled interfaces -- we try to do it through open APIs and the like, but more often than we want we're forced to go sit down with what is -- in effect -- an entirely different project's team lead and patiently explain that yes, indeed, we love their API but our respective bosses and payers of our salary really WANT that connectivity whether they want to open things up that much or not and we're about to start Pointing the Finger of Blame. :)

A good process, in the end, allows for maximum flexibility for individual components, a large scale of flexibilty for the overall system, but protects against feature creep and -- and this is a must -- makes sure the end result actually does what the thing was designed for. Whether it's control the Space Shuttle or makes a fun game.

And therin lies the difference between Agile programming and "Cowboy Coding" http://en.wikipedia.org/wiki/Cowboy_coding

Feature Driven Development is an excellent way to tackle large projects incrementally, especially when coupled with good PM

[SeaCell]

Excellent Article/Interview. Hard hitting and candid.

Only one question for me that was left unanswered,

Is Brad going threw with the operation to get Metal Legs ? I understand it's pretty risky.

[squirrel]

Speaking of -- I bet the wikipedia entries for Brad, Sigil, and Vanguard are a fun battleground right now.

LOL, somebody used the first interview as a reference in Wikipedia. f13 is authoritative!

Oh dear god, help us all.

EDIT: j/k schild, you've pulled quite the scoop. I haven't seen this many 1 - 5 post posters since, well, WAR beta signup...but I fear authority. And influence. And possibly even recognition, but then I'm flaky.

[Jasmine1969]

Brad,

You were a CEO!  I have to say it again....a CEO!  You left it to the office manager, the guy who checks the servers, and some other guy no one knew to inform YOUR employees they all just lost their jobs. Dude, a CEO...and your reason was that you might have cried?   

People several levels below you probably fired many people over the course of their time at Sigil, it ain't easy for anyone...but your're a ...well you get the idea.

I hope you never, ever, ever hold any kind of position ever again where you have to supervise or manage people.
And, the fact that you even comment on the relationship of your friend and business partner in his private life shows you have no morals whatsoever.  It ain't your business, and with all due respect it ain't the public's business ...these three people are just that...real people who have feelings and an absolute right to privacy from their...CEO!......and it has absolutely nothing to do with the rise or fall of the company you were CEO for.

What a moron.

[Nevermore]

So many new posters!

[Sjofn]

So many new posters!

I couldn't help it. You mess with Zoo Tycoon, you mess with me!

[WindupAtheist]

I wonder how much money/effort SOE will actually invest in Vanguard.  I have to imagine they're simply going to clean it up a bit, patch in just enough content to pass it off as a finished game, and then have it live on as a zombie ala Matrix Online and Star Wars Galaxies.

The thing is, why?  Even as mere zombified husks, MxO and SWG at least let SOE put the names "Matrix" and "Star Wars" out there when they're selling Station Passes, and give people burned out on EQ2 something different to do for a little while.  Vanguard has neither of those benefits.

[squirrel]

I wonder how much money/effort SOE will actually invest in Vanguard.  I have to imagine they're simply going to clean it up a bit, patch in just enough content to pass it off as a finished game, and then have it live on as a zombie ala Matrix Online and Star Wars Galaxies.

The thing is, why?  Even as mere zombified husks, MxO and SWG at least let SOE put the names "Matrix" and "Star Wars" out there when they're selling Station Passes, and give people burned out on EQ2 something different to do for a little while.  Vanguard has neither of those benefits.

Volume and low incremental cost? Think about it - SOE maybe a whipping boy around here but they have a tonne of experience in MMOG's and they've demonstrated some capability to revive sagging titles (no not SWG - don't go there - but EQII is greatly improved). Anyway I can only assume they got Sigil and the IP at firesale prices, and their financial commitment will be minimal - as befits a 250,000 sub title. It's an additional Pass title, nothing more. From what I can glean MSoft soaked up a lot of the cost, SOE likely bought it then at heavy discount and then got heavy discount on the remaining Sigil assets. From SOE's perspective it makes a lot of sense, what was the alternative?

EDIT: In my experience - limited in gaming but been in software 12+ years - recurring revenue makes investors and executives bums hum. For firesale prices VG may be a good buy on projected recurring alone.

[Elidroth]

Some of those questions were out of line and I'm surprised Brad answered them.  Speaks to his character to be so forthright - regardless of what you think of Sigil, Vanguard or whatnot.

I'm sure he'll bounce back and learn from the Sigil experience.  He has had more success and given more to this industry than any of the snarky douchebags taking potshots on this forum, that is for-fucking-sure.

You drank too much of the Kool-Aid.  This isn't the first time for this type of behavior on his part, and what he gave to the industry vs what he took from games now 20 years-old is debatable.

Quite the contrary, Aaron was one of the more vocal critics of how things were going before he left Sigil last year. One thing I can tell you for certain, is Aaron does not pull punches and speaks his mind on what he thinks.

[Kalei]

So many new posters!

Hope you don't mind us poking our heads in and saying what an awesome job Schild did with these interviews!

The replies too are very insightful.  It has really answered a lot of questions people must have had in the back of their minds.

Very well done and very professional!  BRAVO to all of you!

[squirrel]

Some of those questions were out of line and I'm surprised Brad answered them.  Speaks to his character to be so forthright - regardless of what you think of Sigil, Vanguard or whatnot.

I'm sure he'll bounce back and learn from the Sigil experience.  He has had more success and given more to this industry than any of the snarky douchebags taking potshots on this forum, that is for-fucking-sure.

Don't take anything personally my young friend. As you can see, Brad and many other people are partaking in this post-mortem, it's a healthy process. Brad's critics here have long-standing and fairly valid complaints, but I doubt you'll see a lot of 'pot-shots' as you term them. Criticism, yes, but then criticism is essential in a learning process.

Also you need to learn something - no question is "out of line". The interviewee can always decline to answer politely and a relationship can continue, provided the interviewer is professional and objective, which I think schild was.

Again kudos to schild for the interview, and thanks to all the rednames and Brad for the commentary, we're still a small community in the grand scheme of things and these events can only help us learn.

[Eindrachen]

I honestly think a lot of McQuaid's mistake were simply in not planning enough.  I get the impression he spent more time running around reacting to situations rather than acting on his on initiative.  Like he didn't make any contingency plans or consider what would happen in a worst-case scenario.

While a lot of things contributed to the problem, a lack of foresight certainly seems to be the running theme here.

And seriously, the way that the firings were handled was just plain shoddy.  That shows very poor character on his part.  Hell, he could have at least paid for a last lunch together somewhere, so they could say they at least got that much at the end.  While they were out, his folks could have secured the building and network and such, and the others come back just to get their stuff and whatnot, say one last goodbye, and head on out.  Anything that would have at least given them one last good memory about Sigil.  Now, all they'll remember is how McQuaid didn't even show up, and how they were just told to get their stuff and GTFO.


The really funny thing is, the drama surrounding Vanguard is probably infinitely more entertaining to me than the game itself ever will be.

Funny... or sad.  Maybe both.

[MikeRozak]

I've *never* seen this in real life.  *Never*.  I've been in QA and development (and various other positions).  And ... *never*.  Especially dedicated testers...  As sorry as it is, testing, even on large projects, is generally a bastard child of the software process.

I've seen it, although it usually works out that 1/4 are full-time SDET (testers that can program an write automated tests), 1/4 are full-time employees, and 1/2 are hired temps for the last half of the project.

I suspect I'm preaching to the choir here, but if you start your testing early you're less likely to get to "code complete" and realize that your program crashes all the time and leaks like crazy. Having testers putting in "bugs" such as "This feature doesn't make sense" and/or "Gameplay is boring here" is a good bit of sanity checking even before beta players arrive. In a sense, it's the job of testers to be negative and point out the flaws, and they can do so much more clearly than beta testers, who just mostly provide usability bugs like, "It sux!", if that. (Mostly they don't report anything.)

WoW, for example, felt as though it had a good army of testers behind it. LOTRO has that polished feeling too. Looking at the LOTRO manual, I see 44 names under QA. Identifying programmer's is less clear because the credits use the term "game systems engineering", "technology platform", "technology engineering", and "service technology engineering"... which sums to 36.

[Jain Zar]

A fascinating interview to be sure.

Of course Vanguard was probably doomed if it wasn't so borked out the gate.  Gameplay few people actually seem to want, coupled with almost no genuine buzz.  Nobody gave a damn really.

Listening to McQuaid it sounds more and more like Kevin Siembieda of Palladium Books.  Insistent his archaic game designs are still worth a damn, terrible management & organization, plus the inevitable "DONT YOU SEE ALL THE PEOPLE WHO LIKE ME?  WE ARE TOO LOVED!!" spiel.

Except Palladium at least releases inexpensive products and can (almost) support their niche group.

Vanguard was like Shadowbane which seems to have had similar problems based heavily on people not caring, poor management/money issues, and a design focus that was honestly not capable of sustaining the audience they desired.

Besides, right now making a fantasy MMORPG is kinda stupid anyhow.  WoW is just so huge its kind of become the D&D of MMORPGs.  (Everything else is niche.  Maybe profitable, but in market and mindshare it aint shit-dawg as some friends used to say.)