posted
Is IT allowed to have a union in the US? To the best of my knowledge, here in Ontario, IT cannot be unionized.
I'm surprised that companies still overwork their staff like this still. You would figure after the mass amounts of lawsuits flying around about work conditions this type of practise wouldn't exist (or at least in minimal amounts).
Posts: 28 | Registered: Jul 2006
| IP: Logged |
posted
My stance on unions isn't that favorable. I don't mind that they exist, but only if there is a purpose to be served. (If there are currently bad conditions.)
I look to enter the Game industry. My brother has worked in it for nearly a decade. I think I'd probably put up with the hours, but since I am not in that position I can't say how I'd really react.
Posts: 1132 | Registered: Jul 2002
| IP: Logged |
posted
I'm not a big fan of unions either, but if ever an industry needed one, it'd be the game industry. It's really sick when people can't complain about 60-70 hour weeks with little or no overtime pay for fear of being fired and replaced with someone more "enthusiastic" (and cheap).
Part of this is the culture of fresh-out-of-school wanting-to-prove-themselves willing-to-do-anything-for-experience employees... but a union would definitely help.
Posts: 1681 | Registered: Jun 2004
| IP: Logged |
posted
Huh? What's this? They're blaming the company for a game developer's work hours? Preposterous! A true game developer works those hours naturally, instinctively, without complaints and never experiences this "burn out" thing they're referring to.
"Burn out" symptoms can be countered with sufficient amounts of Red Bull.
While I was a developer at a major company I once logged, in a single week, 107 work hours. Got paid overtime for that, of course. And I loved it!
Posts: 3486 | Registered: Sep 2002
| IP: Logged |
posted
Quit your whining and drink your Jolt cola or something. -- Just kidding, of course; that's messed up, overtime work without overtime pay. Don't companies realize that happier, fresher workers are more productive than burnt-out, tired ones?
Posts: 283 | Registered: Jul 2006
| IP: Logged |
quote:Don't companies realize that happier, fresher workers are more productive than burnt-out, tired ones?
That's true unless the workers don't realize that they're exhausted, because they need the money, or they really, really want the job regardless of the toll it is taking.
--j_k, who put WAY TOO MANY commas in that post.
Posts: 3617 | Registered: Dec 2001
| IP: Logged |
posted
I really want to get into the industry, and honestly would be interested in working those kinds of hours. I really want to be working with games. If I had a wife or kids, it might be a little different, but I think it'd still work out okay.
Posts: 1132 | Registered: Jul 2002
| IP: Logged |
posted
What kind of hours, raventh? 107 a week, or just 70? Which would be 10 hour days 7 days a week. For months and months and months.... You don't think you'd start to get a little burnt out, going in and moving the same darn pixels around every day for 10 hours?
The problem is, young inexperienced folks come in to these places MORE than happy to work these sorts of hours for measly pay, because they're working in Video Games, the holy grail of careers. What they don't usually consider is that their minds and bodies* can only endure so much before they need a break, and if you're working for an unsympatheic company that only cares about the bottom line, they aren't going to wait for you to get nursed back to health (and start demanding fairer hours and better planning), they're going to let you go and hire someone "fresh" to go through exactly what you just did.
This is getting better, I believe, the EA Spouse-related lawsuits have really spread awareness... but as long as there are people who are willing to sacrifice their mental and physical health for a year in the games industry, I think we need someone to protect them and the more mature employees whose work they're devaluing.
*(no matter how much caffeine you drink and how little of a life you need outside work, you can't argue with the dangers of RSI. It's something we all have to deal with in CG, and working 70 hour weeks for 5 months at a time is a quick path to career-ending injury.)
Posts: 1681 | Registered: Jun 2004
| IP: Logged |
posted
OK, how 'bout a more serious answer here...
This article leads one to believe that it's *always* like that. It's most certainly not. Here, for example, is the complete development cycle I experienced for Deneba Software's Canvas, version6. Dates have been changed to make it easier to understand the timeline.
JANUARY 1st: The version is annnounced, and after a long, arduous meeting the higher authorities put together a "to do" list and, based on that, predict the product can "go gold" in 12 months.
JANUARY 2nd-14th: Higher authorities meet with the respective programmers and assign duties based on the "to do" list and each individual's expertise.
JANUARY 14th - NOVEMBER 1st: The lead developer will do the most visible progress during this time because it's his nature and he enjoys it, experimenting with things here and there. Everyone else flounders about and makes little progress. Of the 300 items on the list, two are "complete" but pending testing.
During this time programmers work whenever they feel like it, keeping a close eye on the automated time clock to ensure they don't work a second over the 40 hours, 'cause there is no overtime during this time. Most of the time that is logged is done doing experimentation in code, working on "neat new features" that aren't in the original specification, and playing the First Person Shooter of the month with other co-workers.
NOVEMBER 7th: The marketing executives realize that a competitor, Adobe, is releasing their product within the next month, and it will potentially jeopardize our product's marketability. The marketing executives are also unaware that absolutely nothing has been done, because it's unthinkable to them that ten months went by with little progress.
So, in an effort to beat our competitor to the punch, they accelerate the timeline and ask that the project "go gold" by December 1st.
NOVEMBER 8th: Widespread panic. Managers realize that there's a long way to go and little has been done. They don't blame the programmers because this is the way things have been done for centuries, but now they have to do whatever is necessary in order to meet the deadline. They institute guidelines equivalent to "get this working no matter what or die, but you have two days" rules.
NOVEMBER 9th - NOVEMBER 28th: From one day to the next, the whole mindset changes. Most programmers suddenly realize that they will have no life (well, less of one, anyway) for the next month and will effectively be living in the office. They proceed to make the office their home: bring in comforters, sleeping bags, and enough Jolt Cola, Red Bull and Cheetos to feed India. They make friends with the local pizza establishment to get better pricing on the six pizzas a day they will most probably be ordering for the next month.
Programmers work the extended hours, but the Quality Assurance department does not, so during off hours programmers have to test their own product. Now, if you're not aware, a programmer should NEVER test his own work; he knows what it's supposed to do, but QA's job is to check what it's NOT supposed to do. Needless to say, work done by the programmer in the off hours tends to be more quirky than that which is done with QA present, leading to more testing.
NOVEMBER 29th: Two days from the deadline and there are still things that aren't done or haven't been started. Managers sit down with the marketing executives and begin to go through the pending items list and bug reports, effectively going through each item and wondering "well, do we really NEED this?" and "can we make this a feature in the next version?" and "is this a 'showstopper' or can it wait for a service pack?" The list is pruned to the bare necessities to make a shippable product, which is probably only a couple of the larger things, and extremely vague ones at that. For example, they decide that "printing must work," but don't provide details as to what about it doesn't work.
Those programmers that are required for these sections are expected to work 85 hours a day if need be to get them fixed. The rest of the programmers are either asked to test the product, which ends up being extremely innefficient as they find nothing apparently wrong but testing continues to prove them wrong, or the less-than-useful programmers are sent home to hibernate for a day or two.
DECEMBER 1st: The product is usable, but still has bugs in it. Nonetheless, it "goes gold," and a team is immediately put together to begin working on the first service pack.
DECEMBER 2nd: A major flaw was found. The printing press is called, told to cancel the order, and the product "goes gold" AGAIN.
DECEMBER 3rd-5th: The product ends up going "gold" SEVEN TIMES before it's pressed and ready for publication.
-=O=-
So there you have it. The situations they describe only occur for about a month in the real world, and even then it doesn't happen to every programmer at the office.
Posts: 3486 | Registered: Sep 2002
| IP: Logged |
posted
I'm not sure that the best defense for those hours should be "if we were more competent, they wouldn't be necessary at all."
Posts: 37449 | Registered: May 1999
| IP: Logged |
quote:I'm not sure that the best defense for those hours should be "if we were more competent, they wouldn't be necessary at all."
If marketing and management were more competent, the hours would be far less necessary. That is a general problem with computer compnaies; there are very few places where the suits understand how to manage the geeks.
Posts: 87 | Registered: Apr 2006
| IP: Logged |
posted
Perhaps they could just fire the geeks who refuse to be managed? I'm speaking here as both an occasional geek and an occasional manager: geeks aren't a special case. They're employees.
Posts: 37449 | Registered: May 1999
| IP: Logged |
quote:JANUARY 14th - NOVEMBER 1st: The lead developer will do the most visible progress during this time because it's his nature and he enjoys it, experimenting with things here and there. Everyone else flounders about and makes little progress. Of the 300 items on the list, two are "complete" but pending testing.
During this time programmers work whenever they feel like it, keeping a close eye on the automated time clock to ensure they don't work a second over the 40 hours, 'cause there is no overtime during this time. Most of the time that is logged is done doing experimentation in code, working on "neat new features" that aren't in the original specification, and playing the First Person Shooter of the month with other co-workers.
No freaking kidding. If management thinks it's acceptable for the majority of the programming staff to piss away 90% of the development cycle on playing video games, then something needs to change.
That said, I do think that the video game development cycle differs from the computer software dev cycle, namely because of the huge, huge number of people willing to work very hard for very little. I doubt you see as many people throwing themselves at an opportunity to write a painting program, as fulfilling as it may be.
With video games, I think the "crunch time culture" is brought on far more by the management, rather than the developers and artists, because the management knows that people will tough it out if they want to keep their dream jobs. So instead of planning properly and hiring more staff to handle increased workloads, they just buy the geeks some pizza and tell them they're sleeping at the office till it's finished. What fun.
Posts: 1681 | Registered: Jun 2004
| IP: Logged |
posted
It's not all that surprising, but it does seem colossally stupid. I mean, really, paying people to play video games seems like a path to oblivion for a company.
Maybe someone should make a SIM game called "product cycle" and let managers play it a few times.
Cripes!
Anyone hear of Gantt charts, Critical Path Method, PERT?
quote:Anyone hear of Gantt charts, Critical Path Method, PERT?
I've had a few Gantt charts waved in my face before, sure. By sales and marketing people, of course; the head of R&D threw those out the second he got them.
Posts: 3486 | Registered: Sep 2002
| IP: Logged |
posted
As much as sales & marketing folks might not understand the technical side of things, they do understand that if you don't have a product to sell, eventually you all are out of jobs.
And, if your company earns a reputation for never doing anything on time, or if everything is released full of major bugs...well, same deal.
Posts: 22497 | Registered: Sep 2000
| IP: Logged |
quote:the head of R&D threw those out the second he got them
Then -- and I mean this in the best possible way -- your head of R&D was incompetent.
It's one thing for marketing to not have an accurate grasp of your dev cycle. It's another to not have a dev cycle. Posts: 37449 | Registered: May 1999
| IP: Logged |
quote:the head of R&D threw those out the second he got them
Then -- and I mean this in the best possible way -- your head of R&D was incompetent.
It's one thing for marketing to not have an accurate grasp of your dev cycle. It's another to not have a dev cycle.
He was my cousin. And, yes, you're right.
A lot of gaming companies still abide by the "when it's done" development cycle. Of course, you then get situations like Duke Nukem Forever, Team Fortress 2, etc... But some companies can get away with doing that: Valve Software made so much money off of the original Half-Life and CounterStrike that they could afford a complete media blackout and complete rewrite of the engine twice for three years.
Posts: 3486 | Registered: Sep 2002
| IP: Logged |
posted
Have you read "Rapid Development"? I think it's a must for every person responsible for another programmer's output - including senior developers who supervise junior developers.
Posts: 26071 | Registered: Oct 2003
| IP: Logged |
posted
That sounds terrible, Nighthawk, and unlike the 3 companies (IBM, ATG, and Unica) I've worked for, as QA. QA is often known to put in plenty of hours. Devs do as well, and they don't piss away 80% of the development cycle. I have lots of issues with different development projects I've been on, and they've run the gamut of being due to infrastrucure/tools, process, and personality clashes. Playing FPSes (and similar behavior) isn't that common (but it isn't unheard of, but I've not experienced it myself to your extent.
Printer-friendly view of this topic
![[Smile]](smile.gif)
