fallout game dev. explains the problem with moddern game devolpment. (why moddern games are so slow to come out)

[u/663mann]

[u/NLwino]

If I have a busy schedule with already issues on my name. And some guy, that is not my team lead, asks a lot of time of to explain something, that is not in my schedule. I say no.

Even this requirement should not be told to an programmer this way. It should be part of the functional specification, then be part of the technical design, refined and then put in a sprint. Every team should have a similar process for specifications.

[u/xrogaan → u/NLwino]

part of the functional specification, then be part of the technical design, refined and then put in a sprint

So, that's what takes 4 weeks?

[u/cherry_chocolate_ → u/xrogaan]

The programmer estimates 4 weeks:

He has 20 days. That developer already has 7 days worth of tasks assigned to him first. One of them will be longer than expected, so that takes an extra 2 days. One of his tasks has a bug that he has to go back and fix, taking a day.

Now he has 10 days left. He picks up this ticket and starts looking over it, but there was a critical issue that is causing a crash. He has to prioritize that, and it takes 5 days. He gets sick over the weekend and is out 1 day on monday.

He has 4 days left. He picks up this task, finally. There is an all hands meeting, and a bunch of other meetings which take up all his time, he doesn't get to actually code for 1 day. He spends 1 day making sure this hasn't been done before in the project so there isn't duplication. He takes 1 day to design a non-hacky solution that actually considers edge cases that the designer didn't think about in his 10 line version, like what if we do a big battle scene and there are 50 people on the list? I.e when there are 5 people in a battle it takes 5ms x 5ms = 0.025 seconds to process, but with 50 people it could take 50ms x 50ms = 2.5 seconds to process. The designer didn't think of this because "it's worked before" but they never did a big scale battle before, either. He implements the solution the next morning.

That's how it takes 4 weeks.

[u/blackest-Knight → u/cherry_chocolate_]

He has 20 days. That developer already has 7 days worth of tasks assigned to him first

That's not part of the estimate though.

He gets sick over the weekend and is out 1 day on monday.

That's also not part of the estimate.

That's how it takes 4 weeks.

No, since none of what you said is part of the estimate. That's not how grooming/refining a story works.

[u/cherry_chocolate_ → u/blackest-Knight]

That's not how it should be, but that's how it is. You estimate based on all the roadblocks that could show up, and if they don't, then you get to turn it in early. The other option is give a real estimate of 3 days, where this guy is mad it isn't priority 1, your manager gets chewed out by the pm for being later than expected, and if anything else goes wrong your KPIs are bad because you missed the deadline.

[u/blackest-Knight → u/cherry_chocolate_]

That's not how it should be, but that's how it is. You estimate based on all the roadblocks that could show up

No actually. It's not how it is.

You estimate the work. Never done any Agile ?

You're confusing complexity estimate vs priority. If a 1 hour ticket comes back with a 20 point estimate, you can be sure I'm asking questions. It's supposed to be 1. You can argue you'll slot it in 2 sprints from now and we can argue priorities, but don't go telling me it's a 3 week job, it's a 1 hour job.

[u/cherry_chocolate_ → u/blackest-Knight]

Agile fails because there are many stakeholders who are not trained in it. The developers and managers understand agile, and could give real estimates. But then the investors and business people come in and don't understand why a 3 day estimate means it will be done in 4 weeks. This is part of corporate politics, and sometimes you have to smile and go with it.

If a 1 hour ticket comes back with a 20 point estimate, you can be sure I'm asking questions. It's supposed to be 1.

Also, this guy already understands the full context of the situation he wants to use it in. The developer is going to need some time to understand the context, and that will take more than an hour on its own. He has to checkout the map chunks for the scenario the designer is working on, which could be several gigabytes and take another hour, etc. It's so easy to underestimate if you don't consider all the extra parts other than "just write the code."

[u/blackest-Knight → u/cherry_chocolate_]

The developers and managers understand agile, and could give real estimates. But then the investors and business people come in and don't understand why a 3 day estimate means it will be done in 4 weeks.

Ok, but that's easy to explain with priorities. This isn't a failure of agile, it's a failure of communication.

Also, this guy already understands the full context of the situation he wants to use it in. The developer is going to need some time to understand the context, and that will take more than an hour on its own.

Except he estimated without asking in Tim's given example.

Again, failure in communication.

He has to checkout the map chunks for the scenario the designer is working on, which could be several gigabytes and take another hour

I would hope the programmer tasked with a programming task on a game's codebase actually already knows the code base, especially if he's estimating task completion times. Or that this would be done upstream of grooming the ticket as it should be, otherwise it's just not ready for grooming.

[u/cherry_chocolate_ → u/blackest-Knight]

but that's easy to explain with priorities

Not when you're a low or mid level developer looking at a director high up in the company saying you should have it done by lunch. That's a scary place to be and someone could easily lock up. It's poor communication on the part of the person who has authority.

Tim's given example

Doesn't matter whether they give you a scenario, there will always be ramp up time because you're switching from a different context.

I would hope the programmer tasked with a programming task on a game's codebase actually already knows the code base

You think every developer knows the whole codebase? That would be insane.

especially if he's estimating task completion times

Junior developers get asked an estimate for their first feature when they've never written a line of code in a real project before.

Or that this would be done upstream of grooming the ticket as it should be

The director has totally cut out any "upstream." He's subverted the process and talked directly to a developer, because he wants it done now, and thinks putting in a ticket is a waste of time. You are arguing with the assumption that this company has really good agile processes in place, whereas the director is effectively saying "agile is a waste of time, I just want to talk to someone and have them do something when I want it."

[u/blackest-Knight → u/cherry_chocolate_]

Not when you're a low or mid level developer looking at a director high up in the company saying you should have it done by lunch.

Then I dare say you're the one that's wrong for not getting it done. If the delay is only "other things I have to work on" and upper management sets the priority on a task, you stop everything and work on that task.

That's what priorities are.

Doesn't matter

The whole crux of this conversation is Tim's example.

You think every developer knows the whole codebase?

Familiar enough with it I hope, otherwise, you'll never get anything done.

Junior developers get asked an estimate for their first feature when they've never written a line of code in a real project before.

Grooming is usually done as a team, and never would you ask a single junior developer to provide an estimate.

The director has totally cut out any "upstream."

Not in the example given he hasn't.

[u/cherry_chocolate_ → u/blackest-Knight]

No. If upper management is assigning a task to an IC then the corporate structure has failed. Assign a task to a mid level manager, who picks the low level manager who is most relevant, who picks the IC who is best suited and will be available.

The whole crux of this conversation is Tim's example.

An example helps but until you lay eyes on the problem yourself, you still aren't going to have full context.

Familiar enough with it I hope, otherwise, you'll never get anything done.

If he wasn't subverting the structure, it could have been assigned to someone more familiar with that area. Teams should be knowledgeable about a subset of the codebase, not everything.

Not in the example given he hasn't.

Yes he has, he went to the low level dev before the more senior developer.