Suggestion: Agile Development and Release to Production

[Hydrino]

FD should follow not only agile development, which FD seems to do, but to release new content/ mechanics/ etc. when ready and not save new features for a big patch update like 2.0, 2.1, etc.

If FD are truly going to release 2.4 Thargoids like this, then why not more features when ready, in similar fashion?

dissimilar to downloading via disc; Possibly tied to the need for more client updates and the bandwidth usage?

 

[NW3]

Good idea. Unfortunately, I can think of 2 reasons why FD isn't likely to do that.

1. In the past, players complained about having too-frequent downloads. People who don't play everyday found themselves having to do a download each time they wanted to play.
2. Personally, I don't think FD has the testing in place to do frequent releases. There seem to be really bad bugs in nearly every release they've done, even with weeks of beta testing.

 

[dogsolitude_uk]

Problem with Agile development is that you end up with a lot of technical debt and it's easy to develop yourself into a corner via path dependency.

It does keep the customer happy with frequent updates so Agile is brilliant for startups, proof of concept and simple, smaller one-off projects, but can lead to a very chaotic and difficult-to-maintain codebase in anything large. I suspect the difficulties with providing HUD colour options are due to this for example (possible scenario: in order to get HUD sorted for the end of a sprint, colour values in shaders would have been hardcoded in multiple places rather than passed as parameters).

Agile can get quick changes to market/customers fast, but you can end up with a very Heath Robinson codebase!

A well-roadmapped iterative design process would be better I think. Perhaps with the community voting on roadmap priorities?

 

[NW3]

Problem with Agile development is that you end up with a lot of technical debt and it's easy to develop yourself into a corner via path dependency.

Agile can get quick changes to market/customers fast, but you can end up with a very Heath Robinson codebase!

A well-roadmapped iterative design process would be better I think. Perhaps with the community voting on roadmap priorities?

Agile processes do not HAVE to lead to code debt. The team I work with follows a modified agile process. For each 2-week sprint, we sign up for some defects as well as new features. The defects get fixed first, then the features are added. Defects can include "maintenance" tasks, which includes refactoring code debt.