Now, I don't dislike Eladrin; but my god, man... this is why Live is such a basket case!

http://forums.ddo.com/showpost.php?p=4938206&postcount=60

Get on live (the production one) and frakkin' play a while!

You would  see that it looks NOTHING like your non-prod copy.  If it did, maybe things would be getting fixed that really need it instead of dumb shit like the notch in the chat window.

Get out of the bubble!

I don't understand why he can't sing into live just to throw a wail and see it not working, that doesn't make any sense.

What would he sing to find out if wail wasn't working?

Bigjunk wrote on Mar 11^th, 2013 at 3:11pm:


And associate with the riff raff? Pffft

Has the "casting a hold spell on certain creatures crashes everyone's client" bug made the official noticed list yet?

I'd expect no less from the DDO Devs at this point.
Very little of their desperate grasping at mediocrity surprises or infuriates me any more.

"Must be Adequate - no more/no less." seems like a prerequisite of being hired.

Allo wrote on Mar 11^th, 2013 at 4:05pm:


Ya, we got crashed out last night in Belly of the beast after the wizard cast a hold spell at a worm.

Memnir wrote on Mar 11^th, 2013 at 4:08pm:


"Must be Adequate" may be a prerequisite for being hired, but Turbine's corporate culture apparently tolerates much less once they have an employee badge.

Quote:


I respect the hell outta the guy, but man, not having a debug environment that mirrors live as a reflex action is... Jesus H Christ on a crutch... ithurts.

The way Eladrin explained it is awful.  The concept is sound.  You do not run diagnostics on production.  You do have a testing platform that is identical to live for the purpose of reproducing bugs and isolating.  Also used for stress testing. 

Anyone thinking that a dev should "pop onto live", fire up their diagnostics and logging and test out some bugs is asking for major lag, amongst other things, and probably doesn't have any idea what they are talking about.  I would fire a developer for running such on a production blade with paying clients.  Now, where I work, we have the ability to redirect customers to other blades and run tests on the environment that the error was reported on in addition to our testing blades/virtuals, but no well designed evironment includes "popping onto live" and firing off diagnostics.

All the above said, the idea would be stupid in my environment, but that may or may not be the case for Turbine.  We make a TON of assumptions as players about how they have things designed and architected and what their procedures are and it is very easy to pass judgement based on our assumptions.  But really, we are uninformed as to what their configuration is, testing options and procedures are, and whether they are well designed, implemented or utilized.

Of course, there is one thing we CAN evaluate.  The results, in terms of mean number of failures per release and mean time to repair, are shockingly poor and indicate either poor architecture or poor procedures, or both.  Probably combined with poor execution by the team for the triple play of software.

Asheras wrote on Mar 11^th, 2013 at 5:02pm:



There has to be a way to connect the developers to what is what is broke, and what isn't broke. From what I experienced when I played, and from what I have read here is there is no clear way for them to figure out what is wrong. The same problems are reported, and ignored. Where is the disconnect?

karatekid wrote on Mar 11^th, 2013 at 5:34pm:


okay, then if they just look at the bug what does that do?

with no diagnostic tools it is impossible to fix.

Dear Turbine,
Please don't take development tips from someone who is too dumb to run Shroud.
Love and bug reports,
Gawna