stusser
4608
Check out the high-level overviews, they’re the linked pictures. None of them goes further out than September 1st.
So either they’re going to finish such extremely high-level milestones as “Persistent Universe Content” and “Gameplay” in the next 2 week sprint or they’re utter bullshit.
We all know the game isn’t gonna hit real alpha (ie, feature-complete) in 2 weeks. So either say “this is what we’re working on this sprint, and we’re giving you unprecedented visibility into the day to day development process” or provide the milestones with actual burndown charts, which you’ll notice are not actually included in the post.
My company develops two products, I have high-level oversight on one of them, and even I don’t give a shit about what they’re doing in each sprint. I want the executive overview, roll up all the bullshit project tasks, tell me where we are, and let me know the blockers so I can aggressively resolve them. I want burndown charts. That’s what this promises but doesn’t provide. Anyone who’s ever worked as a developer or alongside development knows this is all smoke and mirrors.
dsmart
4609
Oh you’re gonna love this:
dsmart
4610
Here’s the thing. It’s all pure and utter bullshit. Back in late 2016 when sources told me that “3.0 didn’t even exist”, back in Aug 2016 when Chris was claiming it was coming on or before Dec 2016, some backers didn’t take me seriously. We’re a year in.
The schedules are the carrot stick used to keep backers giving them money. So they have every reason to keep manipulating the schedules in any manner that keeps the money flow smooth.
Except that even the approx 2K whales still giving them money, are at their limits. So 3.0 is going to be all kinds of hilarious if they release it in the same shoddy manner that they did 2.0 back in Dec 2015.
Also, get this, word is that in Gamescom next week, the streamers who were invited to the event, are going to be playing the current 2.6.3, and not the much touted 3.0 which apparently Gamestar.de and PC Gamer claimed to have played almost two months ago. Backers haven’t played it. And they forked out $156M thus far.
stusser
4611
I’m generally fine with burndown charts, which again you’ll notice they did not actually provide in this post. They are useful tools.
You do need to have estimated dates and effort (generally expressed as story points) on each major milestone and quality gate or the project slips forever. I encourage dev and project managers to be conservative on their dates, to leave some wriggle room for Murphy.
If they miss their deadlines they need to defend/justify why each and every time, and that is all taken into account in their KPIs and takehome quarterly bonus.
Note they do have charts labeled burndown, but they say “we just entered this phase so they aren’t accurate”. Since a burndown is just a simple chart of created vs resolved issues, what that means is they haven’t been using any sort of disciplined issue tracker throughout development, which is completely fucking bonkers on a project of this size.
As seen at the 10 second mark of that video, this content is purportedly produced using their community subscriber program as a separate pool of funding. My impression is that the video is meant to explain these normal development practices to their backers who may not work in that field.
Those milestones are the categories that you’ll see expanded upon if you scroll further down, with the individual tasks listed.
For example, the remaining task on “Persistent Universe Content” is as follows:
MISSION GIVERS
We’re introducing Miles Eckhart (first seen in the Gamescom video) and Ruto to provide missions to players.
We’re aiming to complete Ruto’s initial setup in Subsumption today, but there will be further support needed from both Gamecode Engineering and Graphics Engineering after this point.
ETA is 25th August (was 11th August)
All of the tasks in “Gameplay” are already feature complete, according to their schedule.
stusser
4613
I find it disgusting that such a thing as a $20/month “community subscriber program” exists for an unreleased game, but your point is made. Those suckers are knowingly paying for that content.
So then once they have mission givers in and QA’d, the persistent universe is done. Check it off the list. Right?
But wait, what about the support needed from gamecode and graphics? Code and graphics are kinda big deals. Is this milestone just writing the quests themselves, or the server-side processing?
And even once all that stuff is done, it’s only complete for an arbitrary pre-alpha milestone which they labeled 3.0. It isn’t done for actual final release, right?
Also, Gameplay isn’t complete, because they’re still finding and fixing bugs on most of the major features. Perhaps initial implementation is complete, but again… who gives a shit about that level of development detail?
Man, my brain doesn’t have space for all that whinging.
The description for that task is saying that the gamecode and graphics support will continue up until the 25th before that task is completed (although it will very possibly be delayed again).
Correct, this production schedule is just for 3.0.
I said “feature complete”, which is what it says on the schedule. Doesn’t the term “feature complete” leave room for bug fixing?
stusser
4616
It absolutely does, but my argument is who gives a shit if it doesn’t work yet? They’re providing information to their community that doesn’t actually indicate anything meaningful. It’s deceptive.
Burndown charts are meaningful because they show how development is actually progressing. QA finds bugs, developers address them, and that process iterates until the feature is good to ship.
Can QA start their work on a task before it reaches feature complete status?
Also,
That chart is specifically limited to issues that they feel must be fixed before they release 3.0 to the Evocati player test group. They mentioned in the latest Around the Verse that they have many more bugs tracked for the general 3.0 branch.
Lantz
4618
I want to see the burndown chart for the developers’ accrued vacation time. None of them are going to want a lot of time banked when this blows up.
I have never seen a software project where lots of groups keep announcing small delays where they are actually anywhere near ready. I would bet huge money that they are all playing chicken waiting for one of the other groups to finally crack and admit how far they are behind and take the heat. Particularly since the groups are spread across different studios in different countries. I have been on that ride, can’t recommend it.
stusser
4619
Dear lord. Yes. QA and development should be working together very closely for the entire duration. That’s how modern development works, devops, continuous integration, very frequent releases, break fast and fix as you go.
I ask that because I recall seeing this in the description of one of their items (Render To Texture):
This system is still in progress, but due to its overall size and some of the other features for 3.0.0 that require Render to Texture, teams are using the system as soon as they are able, which means that Render to Texture is requiring bug fixing support while it’s being developed which results in further delays of the system as a whole. The date below does also take dedicated bug fixing time into account.
Which implies that the individual items do not typically receive bug fixing support until they are feature complete.
wilykat
4621
It kind of depends on what you mean by “a task”. Generally the way software production happens is that a big task (e.g. “create YouTube”) is broken into smaller tasks (“login”, “upload video”, “display video”, “comments”, etc.) and each of those is made up of tasks (“create new account page”, “verify that user isn’t already a member”, “write username and password to database”, “send confirmation email”) and so on. At the lowest level, each of those things should have something called a “unit test” associated with it to verify that the small piece actually works as expected, and then when you hook them together you might have to test some interactions but you should know that each small piece does what it’s supposed to.
For something like graphics rendering, there are likely some tasks that just accept the rendering as some kind of plug-and-play thing where they just call the “render” method and it happens, and if the system is built well it should be irrelevant how “render” is actually implemented, and those teams can keep developing while it’s still in progress. But there are other teams that are probably blocked until that’s done; you can make “mock” or fake implementations that let you still get some work in but if you can’t predict the performance there’s only so far you can go with that.
It sounds like “Render to Texture” is nominally complete but insufficiently tested, but they decided to go ahead and let other teams work with the prerelease code and that’s caused some bugs to become visible. Normally you’d want to be pretty sure your stuff works with your own tests before you let other teams do it. So in general individual items should be having their bugs fixed without impacting everyone else.
I think your confusion is in that being “feature complete” to the point where you can claim something is done implies that the bug fixing is already finished so the idea of “not getting bugs fixed until the task is feature complete” isn’t really a thing.
This has only made me more confused, since I thought something becomes feature complete before the bug fixing has been finished.
Lantz
4623
One thing to realize is that during integration phases is that it is not only coding bugs that are discovered, there are design and architecture bugs. These can often result in huge rework across multiple areas that were considered done that now need major work. That is a reality for any large project.
stusser
4624
It’s valid enough to say “feature complete” refers only to the initial implementation, but like I posted earlier with the 90/90 rule and Lantz notes, there’s a lot more to development than the initial implementation. To such an extent that it really is deceptive to tell endusers you’re “feature complete” when a feature hasn’t passed QA and isn’t ready to ship.
For comparison, here is the final production schedule from Alpha 2.6. What is particularly useful about this is that the dates are not speculative, since this was created as a retrospective after the update went live. As with the 3.0 schedule, the colored bars indicate the dates in which all of the items in those categories became feature complete.
Different teams use different meanings. I don’t like using feature complete until the bugs are done because it can sometimes encourage developers to put out a buggy feature that they know QA will kick back to them, but it will at least hit the feature complete deadline.
Sorry to jump in so late in the discussion, but what is this? They have some kind of subscription club to get more info?
