How software development actually works (and how Facepunch is Failing) - Rust

[QUOTE=BleedingGreen;46407491]"a flexible, holistic product development strategy where a development team works as a unit to [B]reach a common goal[/B]"[/QUOTE] Little farther down it gets more specific. "A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that [B]unpredicted challenges[/B][B] cannot[/B] be easily addressed in a [B]traditional[/B] predictive or [B]planned[/B] manner. As such, Scrum adopts an empirical approach—[B]accepting that the problem cannot be fully understood or defined[/B], focusing [B]instead[/B] on maximizing the team's ability to deliver quickly and respond to [B]emerging requirements[/B]."

[QUOTE=DeadRisen;46407666]Little farther down it gets more specific. "A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that [B]unpredicted challenges[/B][B] cannot[/B] be easily addressed in a [B]traditional[/B] predictive or [B]planned[/B] manner. As such, Scrum adopts an empirical approach—[B]accepting that the problem cannot be fully understood or defined[/B], focusing [B]instead[/B] on maximizing the team's ability to deliver quickly and respond to [B]emerging requirements[/B]."[/QUOTE] The downside if this, as is apparent, is increased defects, and incomplete functionality. This approach attempts to create a picture using stipple, instead of long brush strokes... that's why its so unclear to people what the actual goal is.

Did I mention I love SCRUM? It is very uncommon for a software development course to mention it, let alone cover it.

[QUOTE=BleedingGreen;46407699]The downside if this, as is apparent, is increased defects, and incomplete functionality. This approach attempts to create a picture using stipple, instead of long brush strokes... that's why its so unclear to people what the actual goal is.[/QUOTE] Increased defects and incomplete functionality isn't a result of scrum. Facepunch isn't using scrum. Their fairly informal use of trello and Garry as 'provider of requirements' may look similar to some scrum activities from the outside, but that doesn't make it scrum. Or agile. Or anything else for that matter.

[QUOTE=DeadRisen;46407711]Did I mention I love SCRUM? It is very uncommon for a software development course to mention it, let alone cover it.[/QUOTE] Its not mentioned because its incredibly inefficient. It does however allow for evolution of content and direction. That may be a good thing long term for Rust, but in the short term... can we please just get something that works well? [editline]4th November 2014[/editline] [QUOTE=StryfeKhaos;46407730]Increased defects and incomplete functionality isn't a result of scrum. Facepunch isn't using scrum. Their fairly informal use of trello and Garry as 'provider of requirements' may look similar to some scrum activities from the outside, but that doesn't make it scrum. Or agile. Or anything else for that matter.[/QUOTE] I would argue that they are using scrum. They make a plan, per week on what to work on, however they also introduce new concepts on the fly.

In the long run, small developer teams waste more time with the traditional approach, perfecting things that due to the nature of their product have to be thrown away. Now when it comes to having 10+ programmers interfacing with each other, traditional definitely benefits. At the moment Garry only has 1 other programmer working on rust right? I think between the 2? of them and with his experience from Legacy's many coding bottlenecks still fresh in his mind, he can guide the game in a way that won't be limited by spaghetti code. [editline]4th November 2014[/editline] [QUOTE=StryfeKhaos;46407730]Increased defects and incomplete functionality isn't a result of scrum. Facepunch isn't using scrum. Their fairly informal use of trello and Garry as 'provider of requirements' may look similar to some scrum activities from the outside, but that doesn't make it scrum. Or agile. Or anything else for that matter.[/QUOTE] I was looking at their trello, it seems to be pretty short term as far as planning. I feel it goes maybe a little more than a month or two ahead in regards to feature planning in detail. Looking at it, it doesn't really feel like a software development method, but instead a tool for benefiting another method(SCRUM comes to mind) allowing a focus and documentation of what everyone had done this week(Scrummy) and what they are planning on for the next month(Scrummy). I mean SCRUM does have some long term general planning (milestones) kept track of by the Product owner. I know it sounds like a bunch of code monkeys measuring cocks weekly and deciding 1 week ahead of time what feature would be good to add to the game. But there's more planning than that in the fine print.

[QUOTE=BleedingGreen;46407380]Then why are they wasting time on implementing extra stuff, and not getting it to baseline. You seem to think that artists etc. can't be working future stuff, while programmers refine current content. You don't have to implement something just because you have gotten it ready. You can wait to integrate, you alluded several times in this thread to the fact that artists are not going to just stop doing what they do to help bring it to baseline. No one says they should or have to. I think it speaks to your lack of understanding.[/QUOTE] Thats exactly what the OP said [QUOTE=Prescription;46399961]Let me preface with a couple things... First, what is Facepunch's desired outcome? [B][U]Is it to create a functional game that people will enjoy? If so, then why are they spending time adding bucket helmets, boots that look like frogs.. etc.. and not addressing the basic functionality of the game.[/U][/B] Software development cannot be open-ended. There has to be a desired date of completion... in this context "completion" does not mean that all development is over... it just means that there is a basic game that is fully functional. There has to be a stable/solid product... that can then be upgraded. Seems facepunch is going for a Ferrari out of the gate. Give people the basic's, and then work on variations of cloths, weapons, tools, after you have refined all of the other major components needed to make the game functional. [/QUOTE] So im not sure what you've been reading... The implementation of clothing artifacts is not difficult or time consuming for Garry as he stated in a devblog very long ago, he now has the programming in place to easily implement new items into the game. Their functionality maybe another story but random clothing? I don't think that takes a huge chunk out of his day. If you look at what the bulk of his updates and posts are it is all stuff that works towards with the OP was saying they should be doing. Performance and stable game play. How many game breaking bugs have you seen introduced into the game along with the clothing? I don't think a single bug has revolved around the clothing.

did people drink the crazy juice? Right now things look like they going in the right direction, Garry has not taken the money and run there have been updates every week, all be it not always positive and sometimes broken. Trying to force a game that is in development to work as a finished prototype is a tall order, since you never know what giant bug is waiting around that next line of code. Be patient, let shit get done...

[QUOTE=Dreldan;46409168]How many game breaking bugs have you seen introduced into the game along with the clothing? I don't think a single bug has revolved around the clothing.[/QUOTE] No, but there have been bugs resulting from the implementation of new features (namely, the locks). Consequently, the devs chose to spend extra time fixing those bugs. In both cases, this was time they could have spent re-establishing more fundamental gameplay elements that existed in legacy but are still lacking from experimental. (protection modifiers from clothing being one example). I'm not suggesting that every element from legacy be re-created in experimental before they start looking to make changes, but rather that they should first re-write code for the features they want to keep from legacy before replacing the stuff they have wanted to scrap. For example, I'm guessing they will still want consumables like food and bandages to be activated using the hotbar. Why haven't they established that before they added something like bear traps? Don't get me wrong; I like bear traps. I just think they could have waited until some of the more basic gameplay elements were in place.

[QUOTE=Boseknows;46409822]No, but there have been bugs resulting from the implementation of new features (namely, the locks). Consequently, the devs chose to spend extra time fixing those bugs. In both cases, this was time they could have spent re-establishing more fundamental gameplay elements that existed in legacy but are still lacking from experimental. (protection modifiers from clothing being one example). I'm not suggesting that every element from legacy be re-created in experimental before they start looking to make changes, but rather that they should first re-write code for the features they want to keep from legacy before replacing the stuff they have wanted to scrap. For example, I'm guessing they will still want consumables like food and bandages to be activated using the hotbar. Why haven't they established that before they added something like bear traps? Don't get me wrong; I like bear traps. I just think they could have waited until some of the more basic gameplay elements were in place.[/QUOTE] I see your point but i really dont think they are wasting as much time on things like that as people are alluding to. Just out of curiosity i went through all their dev blogs from when when they started doing it and i found every mention of baseline and what it means to them. Devblog 15: Is where i first found they reference the term baseline and moving closer to it. Devblog 16: They talk about their current goal and how Garry is making a list of whats needed for Baseline. He defines baseline as = Every feature currently in legacy rust (which includes key codes FYI) Devblog 17: More discussion on moving closer to baseline sleeping bags implemented. He goes on about how basic clothing is needed for baseline but he didnt want to use the same crappy clothing from legacy. In his summary he says they made a lot of progress towards baseline that week and that his next goal is the building system(which includes door locks and keys) and AI. Devblog 19: A little discussion in the summary about the building system being put in place and moving closer to baseline Devblog 21: States that they are trying to finally get some basic clothes in for baseline Devblog 23:Discussing implementing animals which are needed for baseline and talks about whats coming up next in the summary. Devblog 24: Talks about being close to baseline. Devblog 25: He says he hopes everyone can see the progress and see that they are very close to base line, also states he's making a big effort to put new stuff on the back burner. Devblog 27: Garry discusses how close we are to baseline and how he needs to figure out exactly what is left at the point to officially be at baseline. Devblog 28: Discussing flicking the switch, he doesn't mention they are at baseline but he does talk about the importance of why they flicked the switch now because it will make all bugs obvious and light a fire under their ass to get stuff done. Anyways it looks like their doing fine to me, and they've been making nice progress with a small dev team. Sorry i made this up quick i have to leave.

[QUOTE=Boseknows;46409822]No, but there have been bugs resulting from the implementation of new features (namely, the locks). Consequently, the devs chose to spend extra time fixing those bugs. In both cases, this was time they could have spent re-establishing more fundamental gameplay elements that existed in legacy but are still lacking from experimental. (protection modifiers from clothing being one example). I'm not suggesting that every element from legacy be re-created in experimental before they start looking to make changes, but rather that they should first re-write code for the features they want to keep from legacy before replacing the stuff they have wanted to scrap. For example, I'm guessing they will still want consumables like food and bandages to be activated using the hotbar. Why haven't they established that before they added something like bear traps? Don't get me wrong; I like bear traps. I just think they could have waited until some of the more basic gameplay elements were in place.[/QUOTE] Because they aren't developing for playability now, but instead for a good end product.

[QUOTE=Prov3rbial;46413571]Because they aren't developing for playability now, but instead for a good end product.[/QUOTE] Why are the two mutually exclusive?

[QUOTE=Boseknows;46413637]Why are the two mutually exclusive?[/QUOTE] They aren't. Small tweaks that help current playability come in all the time. They can't be allowed to derail development, though. You can't perfect each iteration or you get bogged down into a stall -- thus, they build towards the end goal, fixing whatever can be easily fixed along that path.

I think one of the biggest mysteries of this forum is whether elixwhitetail has ever actually discussed anything about content ever, rather than talking shit to anyone that has anything to say about the actual game. Id be suprised if he actually has ever played rust. [editline]5th November 2014[/editline] Lol he called it dumb but he has no useful content so he didnt respond [highlight](User was banned for this post ("Off-topic/rude. Contribute to the thread or don't post." - postal))[/highlight]