lazy developers?

Soejckdswg · April 2006

we keep getting the excuse that the pre-cu was too messy, too hard, to chaotic blah blah blah..is it me or did they patch the nge cause they were too lazy to fix the problems they made or maybe they were too lazy from the beginning coding that created more problems. i mean it just seems thats a poor excuse to nerf a whole system to a more basic system cause the more complex system was too hard. i mean i would fire one of my employees if they gave the excuse "its too hard" when i know they could do it.

Defiant

iceman00 · April 2006

Originally posted by Soejckdswg

we keep getting the excuse that the pre-cu was too messy, too hard, to chaotic blah blah blah..is it me or did they patch the nge cause they were too lazy to fix the problems they made or maybe they were too lazy from the beginning coding that created more problems. i mean it just seems thats a poor excuse to nerf a whole system to a more basic system cause the more complex system was too hard. i mean i would fire one of my employees if they gave the excuse "its too hard" when i know they could do it.

Defiant

I always found that weak. While I'm more an operations guy within IT, our developers would be fired if they told their bosses "we know you guys really like the custom software we built, but it's simply too hard to maintain."

To which my bosses reply would be "that's why we pay you. The time you spent telling me this you could've spent maintaining the software."

Aetius73 · April 2006

Originally posted by Soejckdswg

we keep getting the excuse that the pre-cu was too messy, too hard, to chaotic blah blah blah..is it me or did they patch the nge cause they were too lazy to fix the problems they made or maybe they were too lazy from the beginning coding that created more problems. i mean it just seems thats a poor excuse to nerf a whole system to a more basic system cause the more complex system was too hard. i mean i would fire one of my employees if they gave the excuse "its too hard" when i know they could do it.

Defiant

I wouldn't call it laziness I would call it incompetence.

Slickinfinit · April 2006

I think they got lazy and the sheer amount of things they removed rather then balance showed this. If they balanced things like: dot weopons, skill stacking, high-end crafted goods and buffs they woulda made pre-cu even better and the 500k peak of subs would have increased rather then the opposite.

Rekrul · April 2006

Originally posted by Soejckdswg

we keep getting the excuse that the pre-cu was too messy, too hard, to chaotic blah blah blah..is it me or did they patch the nge cause they were too lazy to fix the problems they made or maybe they were too lazy from the beginning coding that created more problems. i mean it just seems thats a poor excuse to nerf a whole system to a more basic system cause the more complex system was too hard. i mean i would fire one of my employees if they gave the excuse "its too hard" when i know they could do it.

Defiant

I assume you never worked for a management driven business, working on legacy code, with revolving door employment policy.

You'd be surprised...

Clackamas · April 2006

Originally posted by Soejckdswg

we keep getting the excuse that the pre-cu was too messy, too hard, to chaotic blah blah blah..is it me or did they patch the nge cause they were too lazy to fix the problems they made or maybe they were too lazy from the beginning coding that created more problems. i mean it just seems thats a poor excuse to nerf a whole system to a more basic system cause the more complex system was too hard. i mean i would fire one of my employees if they gave the excuse "its too hard" when i know they could do it.

Defiant

I think the issue is more like:

Are Perl programers or Engineer or just hacks?

I believe that that the DEVs are hacks and fairly clueless when it comes to design. Anyone can implement a design (ie a hack), but not everyone can design (ie Engineer).

duncan_922 · April 2006

I don't think the problem is the coders, it's management... When you're a code monkey, you don't get to say what you work on, you are told. And we all know what the priorities have been since SWG started.

When they were supposed to be working on game bugs, fixes, content, smuggler's revamp... They were really working on JTL.

Afterwards, instead of now working on bugs, fixes, content, smuggler's revamp... CU

And it goes on... One thing that I did agree with Wepps when he was here (the old version) is that he used to say that the problem with SWG was always management.

AH-Cleaner · April 2006

To me it is simple. They were told to have SWG available for Christmas 2006 to play on the PS3

Rekrul · April 2006

Originally posted by duncan_922
I don't think the problem is the coders, it's management...
When you're a code monkey, you don't get to say what you work on, you
are told. And we all know what the priorities have been since SWG
started.

When they were supposed to be working on game bugs, fixes, content, smuggler's revamp... They were really working on JTL.

Afterwards, instead of now working on bugs, fixes, content, smuggler's revamp... CU

And
it goes on... One thing that I did agree with Wepps when he was here
(the old version) is that he used to say that the problem with SWG was
always management.

Yes, but it's generalization of the problem. No one person is
responsible for anything, and everything is about dodging
responsibility, the only bottom line is profit margin.

I worked for a business (not company) with SOE-like business practices. Here's how it works.

- Owner/CEO sets the strategic direction (there's money to be made off SW license)

- Marketing lead finds an unfilled niche (MMORPG)

- In correlation with LEC, they work out basic feasibility

- Sales department lead assigns a study to be made

- Sales department issues reports on TCO and ROI

- People are profiled, resources are evaluated

- Human resources allocates the people

- Content, design, technical, operational leads are assigned

- The develop first designs, overview documents, the paper-napkin brainstorming basically

- This is put back to HR lead to confirm, content is also proofed by LEC

- HR cuts down the slac based on LEC feedback, that is fed back to design leads

- They assign feedback to lower levels, ask them to modify the designs to conform

- Periodicaly from now on (once a week), designers report to their leads

- Leads report to HR, coordinate with LEC, marketing, sales, focus groups and analysts

- Feedback is fed into refinement to lowest level grunts (interns, temps)

- Grunts start producing something tangible (based on LEC feedback on
refined design of LEC feedback based on original Lead design which was
made to conform with strategic vision as enforced by HR, and taking
into consideration the marketing, sales and internal resources)

By this time, 6 months have passed, and the real work starts

- Programmers, artists, asset developers, story writers, technical
specialists, division leads, resource manages, purchasing, and other
divisions are organized into hierarchy

- Middle management is distributed between various sections, they all
report to their section leads, who report to design leads, who report
to CxO assistants, who report to PR, who reports to stockholders.

- The grunts are now starting to produce something, and progress reports are fed through the aforementioned hierarchy.

3 months pass

- First alpha tests begin, test groups, focus groups, alpha testers and QA departments are activated

- QA department receives anywhere between 100-2000 reports a day

- Feedback from QA department is filtered and distributed by QA
personell to apropriate people (anyone in the before mentioned
hierarchy). Since QA is just a standalone department, they have no clue
what product they are working on, they just shuffle tickets based on
keywords semi-automatically

- Middle management receives their daily ammount of tickets. They have
their domain specialists, who filter out their tickets, and estimate
the time required for completion.

- Each department now gets anywhere between 10-200 tickets daily, with each task taking minimum of 30 minutes

- Tickets are ordered by importance, and time to resolve all is estimated at 4-6 years.

- HR allocates 10 hours per week for resolving showstopping tasks. 5 hours buffer zone is added for emergency tasks.

3 more months pass

- Game is launched

- Additional 2000-18000 tickets and bug reports are generated daily

- With bulk of development gone, most existing teams are disbanded

- Maintainance team is assigned to resolving showstopping issues

- Most of grunt force is reassigned, fired, or their contracts are not renewed, if they worked for limited time/scope

- Small teams are assembled to start working on expansions/additions

- These teams start with this procedure from the start

And here you have your business ran MMORPG. While the above is written
with plenty of cynicism, and to some extent may seem absurd, it's
common practice. For a very simple reason.

Such process is simple, it can be separated into logical units, and it
allows for replacement of anyone or anything. Since the process is well
formulated, every single step has an associated cost. Art department
sucking up too much money? Fire two people. Management team complains
about too much work? Replace their lead. Chief gameplay designer
screams about his misunderstood vision? Reassign him.

The bug/ticket numbers quoted above are "real". Last time I submitted
bug/ticket in game, the sequential number was over 4 million.

The time allocations for bug fixes are real, coming from actual
production environment. After the product is finished, that time is cut
even further. Fixing a single bug in hierarchical environment involves
the following:

- QA receives a ticket

- Tier 3 classifies ticket as pass/no-go

- Tier 2 receives the ticket, classifies it, and submits for revision

- Tier 1 forwards the accumulated tickets to appropriate department

- Department X manager receives report of 68 tickets

- 3 tickets are chosen for resolution in next patch

- These 3 tickets are sent for approval by the operations lead

- Operations lead receives reports from all departments, resulting in 98 tickets total

- After reviewing operations plan, 9 hours are available for intern/temp work in resolution of these tickets

- 2 tickets classified as most important are delegate to 2 intern/temp

- Each intern/temp completes the work in 2 hours

- They write testing procedure on how to replicate/verify fix

- Patch is submitted to internal testing

- Internal testing confirms patch deploys ok

- After internal testing, it is deployed to QA testing

- QA testing follows the fixer's procedure to verify the bug fix

- QA confirmes 2 bugs resolved

- Report is sent to QA Tier 1

- QA Tier 1 reports to the department

- Department lead issues report to operations lead

- Operations lead generates report, marking (among other things) work
done by interns (so they could get paid, although they don't)

Once again, this may sound absurd, but when dealing with huge
businesses, this is how it works. I've been running within a similar
procedure in a much smaller company.

I lasted almost 3 years, before I got fed up.

And that is exactly why recently many different organizational
structures and development practices evolved. The factory style
top-down approach is only applicable to the worst and dummest of
problems. Such procedures work well in (for example) nut and bolt
factory. But in a creative industry of game design, it just doesn't.
But it still makes nice money if done properly, so people stick with
that guarantees the profit.

phosphoros · April 2006

Originally posted by Rekrul

Originally posted by Soejckdswg
we keep getting the excuse that the pre-cu was too messy, too hard, to chaotic blah blah blah..is it me or did they patch the nge cause they were too lazy to fix the problems they made or maybe they were too lazy from the beginning coding that created more problems. i mean it just seems thats a poor excuse to nerf a whole system to a more basic system cause the more complex system was too hard. i mean i would fire one of my employees if they gave the excuse "its too hard" when i know they could do it.Defiant
I assume you never worked for a management driven business, working on legacy code, with revolving door employment policy.You'd be surprised...

QFE!
It's not so much the code that's the problem. It's the way they conduct business.
It's standard practice for coders to comment their code. Although sometimes it get very ugly or vague it's there.

It's literally the same problem with Windows. The code is so long and convoluted now no one person has the knowledge to effectively fix/debug the code. You ahve to have tons of eyes on the code and while Mirosoft can hire an army of devs to check the code (never helps mind you). SOE doesn't have that option.
So assume that the code is commented and documented badly. Then toss in SOE's management system and you have a nightmare unfolding.
Obviously, the EQ team did much better with the documentation and commenting so EQ didn't go all loopy like SWG did/does. But on the otherhand SWG was probably 3 times as complex as the EQ code was.
Not to mention SOEs database was total crap from the start.
Anyhow, Let's look at another company as an example. Even though they don't make MMOs. id Software, whether you like thier games or not, turns out quality software year in and year out. Why?
Because they have a corporate structure that lends itself to quality control of a strict sense. John Carmack is the king of code there and if any of you have ever met him you'll understand when I say, there is a sense of "I will smack you down good for shitty code" about him.
So unless you're EA and can keep your coders in tiger cages the corporate structure, as SOE has it setup, does not lend itself well to game making with high quality.
I suppose EQ2 could be considered quality code but the team that produced it, as I understand, was rather small considering and no doubt did awesome documentation on the codebase. Perhaps they learned their lessons from SWG.
Guess we'll see when the DC MMO is released. SOE in DC Comics land.... *shiver*

"DOOMSDAY TO ZONE!"

phosphoros · April 2006

Originally posted by Rekrul

Originally posted by duncan_922I don't think the problem is the coders, it's management...
When you're a code monkey, you don't get to say what you work on, you
are told. And we all know what the priorities have been since SWG
started.When they were supposed to be working on game bugs, fixes, content, smuggler's revamp... They were really working on JTL.Afterwards, instead of now working on bugs, fixes, content, smuggler's revamp... CUAnd
it goes on... One thing that I did agree with Wepps when he was here
(the old version) is that he used to say that the problem with SWG was
always management.Yes, but it's generalization of the problem. No one person is
responsible for anything, and everything is about dodging
responsibility, the only bottom line is profit margin.
I worked for a business (not company) with SOE-like business practices. Here's how it works.
- Owner/CEO sets the strategic direction (there's money to be made off SW license)
- Marketing lead finds an unfilled niche (MMORPG)
- In correlation with LEC, they work out basic feasibility
- Sales department lead assigns a study to be made
- Sales department issues reports on TCO and ROI
- People are profiled, resources are evaluated
- Human resources allocates the people
- Content, design, technical, operational leads are assigned
- The develop first designs, overview documents, the paper-napkin brainstorming basically
- This is put back to HR lead to confirm, content is also proofed by LEC
- HR cuts down the slac based on LEC feedback, that is fed back to design leads
- They assign feedback to lower levels, ask them to modify the designs to conform
- Periodicaly from now on (once a week), designers report to their leads
- Leads report to HR, coordinate with LEC, marketing, sales, focus groups and analysts
- Feedback is fed into refinement to lowest level grunts (interns, temps)
- Grunts start producing something tangible (based on LEC feedback on
refined design of LEC feedback based on original Lead design which was
made to conform with strategic vision as enforced by HR, and taking
into consideration the marketing, sales and internal resources)
By this time, 6 months have passed, and the real work starts
- Programmers, artists, asset developers, story writers, technical
specialists, division leads, resource manages, purchasing, and other
divisions are organized into hierarchy
- Middle management is distributed between various sections, they all
report to their section leads, who report to design leads, who report
to CxO assistants, who report to PR, who reports to stockholders.
- The grunts are now starting to produce something, and progress reports are fed through the aforementioned hierarchy.
3 months pass
- First alpha tests begin, test groups, focus groups, alpha testers and QA departments are activated
- QA department receives anywhere between 100-2000 reports a day
- Feedback from QA department is filtered and distributed by QA
personell to apropriate people (anyone in the before mentioned
hierarchy). Since QA is just a standalone department, they have no clue
what product they are working on, they just shuffle tickets based on
keywords semi-automatically
- Middle management receives their daily ammount of tickets. They have
their domain specialists, who filter out their tickets, and estimate
the time required for completion.
- Each department now gets anywhere between 10-200 tickets daily, with each task taking minimum of 30 minutes
- Tickets are ordered by importance, and time to resolve all is estimated at 4-6 years.
- HR allocates 10 hours per week for resolving showstopping tasks. 5 hours buffer zone is added for emergency tasks.
3 more months pass
- Game is launched
- Additional 2000-18000 tickets and bug reports are generated daily
- With bulk of development gone, most existing teams are disbanded
- Maintainance team is assigned to resolving showstopping issues
- Most of grunt force is reassigned, fired, or their contracts are not renewed, if they worked for limited time/scope
- Small teams are assembled to start working on expansions/additions
- These teams start with this procedure from the start
And here you have your business ran MMORPG. While the above is written
with plenty of cynicism, and to some extent may seem absurd, it's
common practice. For a very simple reason.
Such process is simple, it can be separated into logical units, and it
allows for replacement of anyone or anything. Since the process is well
formulated, every single step has an associated cost. Art department
sucking up too much money? Fire two people. Management team complains
about too much work? Replace their lead. Chief gameplay designer
screams about his misunderstood vision? Reassign him.
The bug/ticket numbers quoted above are "real". Last time I submitted
bug/ticket in game, the sequential number was over 4 million.
The time allocations for bug fixes are real, coming from actual
production environment. After the product is finished, that time is cut
even further. Fixing a single bug in hierarchical environment involves
the following:
- QA receives a ticket
- Tier 3 classifies ticket as pass/no-go
- Tier 2 receives the ticket, classifies it, and submits for revision
- Tier 1 forwards the accumulated tickets to appropriate department
- Department X manager receives report of 68 tickets
- 3 tickets are chosen for resolution in next patch
- These 3 tickets are sent for approval by the operations lead
- Operations lead receives reports from all departments, resulting in 98 tickets total
- After reviewing operations plan, 9 hours are available for intern/temp work in resolution of these tickets
- 2 tickets classified as most important are delegate to 2 intern/temp
- Each intern/temp completes the work in 2 hours
- They write testing procedure on how to replicate/verify fix
- Patch is submitted to internal testing
- Internal testing confirms patch deploys ok
- After internal testing, it is deployed to QA testing
- QA testing follows the fixer's procedure to verify the bug fix
- QA confirmes 2 bugs resolved
- Report is sent to QA Tier 1
- QA Tier 1 reports to the department
- Department lead issues report to operations lead
- Operations lead generates report, marking (among other things) work
done by interns (so they could get paid, although they don't)
Once again, this may sound absurd, but when dealing with huge
businesses, this is how it works. I've been running within a similar
procedure in a much smaller company.
I lasted almost 3 years, before I got fed up.
And that is exactly why recently many different organizational
structures and development practices evolved. The factory style
top-down approach is only applicable to the worst and dummest of
problems. Such procedures work well in (for example) nut and bolt
factory. But in a creative industry of game design, it just doesn't.
But it still makes nice money if done properly, so people stick with
that guarantees the profit.

I missed this and typed my little rant out. Your's is much better not to mention sad... ::::21::

Great post.

viadi · April 2006

its nothing to do with the devs its shitty management not having a clue how to allocate the dev time......

however i'd be willing to bet if they had taken the route of fixing what was broken rather then revaping the game we would not be having this little chat today

Xcathdra · April 2006

Originally posted by viadi

its nothing to do with the devs its shitty management not having a clue how to allocate the dev time......

however i'd be willing to bet if they had taken the route of fixing what was broken rather then revaping the game we would not be having this little chat today

QFE.... I beleive it had a lot to do iwth management wanting results last week and not having the patience to wait. They force all the changes, and when it blows up in thier face its the devs fault. Smed stated it was a highly competitive area, but I would think it was how the devs are treated by management that forced a lot of them to leave $OE. I wouldnt like having some upper managament Hack who doesnt know shit about coding telling me what my deadlines are.. If anything it should of been management saying... We want this this and that... with the Dev stating ok... it will be 4 months to get it all done correctly... Smed blamed a lot of what has been going on with the fact they are loosing devs. I think they are loosing them because they dont agree with $OE is doing / how $OE is going about doing it. If I were smed I would be blmaing everyone else for this mess... And if you look at what they are doing, they are blaming everyone else for the mess...

Vocal minorty

Disgruntled Vets

Devs who jumped ship

Bad coding by early devs...

I think they have jsut about covered all of the excuses except for the one they need... And that would be SMed and Julio stating they screwed up, they dont have a clue what customers want, and then resigning...

Xcathdra

Howdy, Stranger!

lazy developers?

Comments

Howdy, Stranger!

Quick Links

lazy developers?

Comments