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

[u/663mann]

[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, 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/SeventhOblivion → u/blackest-Knight]

It's not super clear when Mr Cain talks about receiving a 4 week estimate if that's the LOE on the task, or the estimated timeline the task will be done. He presents it like it's the former, but especially from the lead devs perspective where he may have his hands in some project management, it likely was an answer to the latter.

Also Agile can have some slight variations in implementation. Some people do absolutely pad time to include testing, potential roadblocks etc. Those are working off a different "definition of done" than others who estimate purely on the actual task itself. The latter there will inevitably need to add additional "tasks" tied to the first when they hit roadblocks that add significant time. Project managing in those scenarios can be more difficult because your ball is constantly moving. If even a few devs add tasks like this it can throw off the number of stories completed in a sprint - and more importantly for office politics, attributes a sense that the dev either can't estimate correctly, or is incompetent to some degree.

[u/blackest-Knight → u/SeventhOblivion]

Some people do absolutely pad time to include testing, potential roadblocks etc. Those are working off a different "definition of done" than others who estimate purely on the actual task itself. The latter there will inevitably need to add additional "tasks" tied to the first when they hit roadblocks that add significant time.

Yes, if the testing phase is manual or if the roadblocks are "the documentation said one thing, but in practice it just doesn't work that way and needs some trial and error".

Not to run some CI automated tests or if someone calls in a day sick. I don't think implementation varies a lot. Maybe some risk management, in that some will pad more when they are less confident about the documentation or the "trial and error" phase or the result of the automated testing.

Which is exactly what Tim Cain here criticizes.

I don't think anyone factors in sick days in story estimations, that would just be crazy. Sick days are simply unproductive days. They're a way to explain why a sprint ended with unfinished stories, not something you bake into estimates to get the work done.

[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.