FD should increase size of the team developing ED

[Cmdr Eagleboy]

There have been lot of posts and claims that FD doesn't have 100-ish people team working on ED. While it has always contradicted by regular FD claims of having such big team for game, I think I realize now that discussion is not about how big team works on ED. We have what FD says us, and we have some assertments like FD being publicly traded company so they can't lie about that kind of information on regular basis.

However, I think it is not the point people try to make there, it just shows limits of Internet as discussion platform. Most of people claiming this seems to be saying such things:

* Game is not what I wanted it to be / what I expected it to be / I don't enjoy it - well, this easiest and in same time most hardest thing. If you don't like a game like at all at fundamental level, it really does not matter how much people working on it, is it. And while people associate bigger teams with "AAA game development", which most likely means scripted and fully voice acted and cut scenes galore, ED was never meant such game. No directly involved story line for everybody or any such developments, open world - do whatever you can do, and so on and so forth. Open world games are always this contraversional - people either love them or hate them. And sometimes amount of money spent on it matters, and sometimes it matters little. In the end, if you do not enjoy such games fundamentally, ED isn't gonna cut for you;

* Game updates are too sparse and not frequent enough - this is most subjective and in same time most honest opinion we can all give. I personally feel OK-ish with updates, but I definitely wish there was more "content" and more frequently. Some people say it is totally unacceptable, and some are fine with it. I certainly enjoy the game, so for me it is just wish that might get fulfilled some day. But if someone is waiting for new feature or improvement, I understand his unease about tempo of development;

In conclusion I think none of that even means anything about size of the team. We just discuss actual output. And it is quite obvious that most of us would like to have more ED in a year. So that all being said, I think FD really should increase size of team developing ED - because we want more ED updates to be released more frequently. I hope they do. I hope that recent David side note about happening will really leave some impact on how much they can release a year.

 

[Whitehair]

Mostly the people posting on this forum claim to be adults. If they are unable to properly formulate what the (their) problem is, then the discussion is doomed from the start as what they say (write) is not what they mean.

 

[bitstorm]

On output I can't help think they lack tools for building stuff, and so much has to be built by hand from scratch.

Look at the in game UI bottleneck issues that have been ongoing since 2013, repeated skin issues we see, limitations on HUDs, how long it takes for content to be produced.

I wonder if it's made worse because Frontier may want a lot of stuff to be procedural, ie perhaps surface sites are procedural. So you can't really build a tool that allows you to handcraft a site, you're instead building algorithms with produce sites, which is going to mean a programmer.

 

[Factabulous]

Not convinced. Most people want their changes, not just more changes.

And you should look at books on productivity in s/w teams - Mythical Man Month by Fred Brooks is a classic. Costs of communication follow a power law, so adding more people doesn't necessarily increase output.

 

[Cmdr Eagleboy]

Not convinced. Most people want their changes, not just more changes.

And you should look at books on productivity in s/w teams - Mythical Man Month by Fred Brooks is a classic. Costs of communication follow a power law, so adding more people doesn't necessarily increase output.

I should explain why I think they should increase size of team. At this point this team have been with ED for 6 years. They certainly have worked out kinks, so they can surely add more people to various departments to increase output. I think 4 updates a year is still very ok, but smaller middle of the year updates could have more QoL things.

 

[thistle]

I think that perhaps we should just wait? I mean we are coming to the end of the Beyond series in Q4, with changes we don't know the extent of (which will have taken significant development effort), and whatever comes next, assuming it's within a year, will *actively be being worked on right now*.

So you cant say they need more people/output - we dont know what has/is being developed currently.

What we DO know is Beyond, and that is following exactly the roadmap we got last year. Everything else is just speculation and impatience. (edit - I'm impatient too lol)

 

[Heater]

Biggest problem is the "marketing hype" vs reality and what people's own expectations are, (mine included)
If you go back to the kick start and beta days, Frontier promised a lot and so far very little has been delivered.
But hey it's a 10 year plan

 

[Cmdr Eagleboy]

Biggest problem is the "marketing hype" vs reality and what people's own expectations are, (mine included)
If you go back to the kick start and beta days, Frontier promised a lot and so far very little has been delivered.
But hey it's a 10 year plan

They didn't promise anything. But sure, for lot of people it sounded like "promises". And "so far very little" is clearly a hyperbole.

 

[lenna]

I think FD really should increase size of team developing ED - because we want more ED updates to be released more frequently.

I seriously hope they ignore threads like these and this perspective in particular.

Increasing team size only increases net productivity to a point, beyond that point the process becomes increasingly inefficient and less cost effective - the old Adage of Too Many Cooks Spoil the Broth is quite applicable to this case.

As for rate of output, there are practical limits to be considered and what FD are currently attempting (4 major milestones a year) is about the limit of what any developer should realistically even attempt with a product the size and complexity of ED.

 

[Koen]

I think FD really should increase size of team developing ED

I think you should read Fred Brooks' The Mythical Man-Month (1975).

"adding manpower to a late software project makes it later"

Full text.

Edit: PDF

 

[Factabulous]

I should explain why I think they should increase size of team. At this point this team have been with ED for 6 years. They certainly have worked out kinks, so they can surely add more people to various departments to increase output. I think 4 updates a year is still very ok, but smaller middle of the year updates could have more QoL things.

Classic fallacy - as I said, Mythical Man Month <shrug>

 

[M00ka]

Not convinced. Most people want their changes, not just more changes.

And you should look at books on productivity in s/w teams - Mythical Man Month by Fred Brooks is a classic. Costs of communication follow a power law, so adding more people doesn't necessarily increase output.

Repped especially for the first line!

To me at least, this is one of the strengths and failings of the game. Because there is no linear path to follow, no hand holding, no set goals to achieve to get a virtual pat on the back, everyone plays the game they way they want to (the Strengths). Unfortunately this results in everyone having a different paradigm on what they think the game should be and how it can be improved - to wholly and solely support their playing style (the Failings). And when the game isn't redesigned to fit their personal ideal on how the game should be, the salt starts flowing, the pacifiers get ejected across the playpen, and the insults flow freely.

 

[Cmdr Eagleboy]

Classic fallacy - as I said, Mythical Man Month <shrug>

I know what it means. But as always, it is not black and white, and while increasing team size doesn't solve your issues faster, with proper mentoring and intermission period there is possibility to improve product in general.

 

[Cmdr Eagleboy]

I seriously hope they ignore threads like these and this perspective in particular.

Increasing team size only increases net productivity to a point, beyond that point the process becomes increasingly inefficient and less cost effective - the old Adage of Too Many Cooks Spoil the Broth is quite applicable to this case.

As for rate of output, there are practical limits to be considered and what FD are currently attempting (4 major milestones a year) is about the limit of what any developer should realistically even attempt with a product the size and complexity of ED.

I don't think this thread is addressed towards FD in any shape or form. I just express my sentiment at the moment. I know it is not easy as that. Also David Braben said they will increase time size. I hope that move will benefit game as whole.

 

[lenna]

I know what it means. But as always, it is not black and white, and while increasing team size doesn't solve your issues faster, with proper mentoring and intermission period there is possibility to improve product in general.

That is highly subjective and a bit of a sticky wicket. IME the kind of mentoring required would invariably result in a significant loss in productivity and also put product quality and/or schedule at risk (depends on various factors but such things can not be ignored).

If FD are anything like a decent software house then they will probably have succession plans in place (or at least plans for what happens in the case of work force replacements). The most cost effective way is probably to document the technicalities of the product properly, mentoring/pair-programming can cost the business more and provide less scope for contingencies. Documentation can be backed up, people's minds currently can not.

 

[lenna]

I don't think this thread is addressed towards FD in any shape or form. I just express my sentiment at the moment. I know it is not easy as that. Also David Braben said they will increase time size. I hope that move will benefit game as whole.

Depends on a variety of factors, but I hope DB does not make the classic legacy recruitment mistakes and keep in mind sustainability of the work force (as well as properly consider the impact of taking on new people).

As for benefiting the game as a whole, I doubt it will be as significant as you seem to hope it will be.

 

[Skip Rockbounder]

I should explain why I think they should increase size of team. At this point this team have been with ED for 6 years. They certainly have worked out kinks, so they can surely add more people to various departments to increase output. I think 4 updates a year is still very ok, but smaller middle of the year updates could have more QoL things.

Let's look at a scenario here.

: Q1, After everyone gets over Christmas they look forward to a big update announced in late January (going along with threads demanding to know what's happening)... unfortunately, little of it is of interest to the 'more vocal' forum users. - ED get roasted as usual.

That's it till Christmas then, because

:Q2, No announcement and release Nothing of interest... except a wing mission can be done and the SRV doesn't explode now, buildings might look shinier too... OK -ED gets roasted
:Q3, same as above, many (more vocal) forum users Claim ED is dying, , owes them for their LTP, and whatever other game is better. - ED gets roa..
:Q4, Yea, it's Christmas... again! "we love you ED", "you broke my ship", "When's the next update?" "What's in it?" "When are you gonna tell us"
... back to top

 

[Ian Doncaster]

Mythical Man Month is talking about the specific case where you're halfway through a project planned to take N programmers X months, realise you're behind schedule, and try to fix that by adding more programmers. The relevance to Elite Dangerous would have been, for example, if they'd tried to fix most of Horizons being late by putting more programmers on it.

If you're starting a new project and can have either X or 2X people on it, then you can generally get it done faster (as long as it's big enough for 2X people to have something to do at all) with 2X provided you plan around having 2X from the start including management of overheads. So any significant increase in staffing certainly wouldn't help Beyond and is probably too late to be planned in for 2019, but might help for 2020 onwards.

My personal impression from which Horizons features arrived and didn't and in what form is that Frontier had enough programmers working on Elite Dangerous, but not enough artists and writers to support the raw capabilities they were introducing with content, because their original plan had been too optimistic about how far procedural generation could get them. I also get the impression that this has been addressed in Beyond, though it may not be until 2019 we really see the results of that.

 

[ToCoSo]

I think this years format is pretty good, I think we are suffering from the 'Horizons effect' where patches were slow, and it felt like Frontier were focusing on their other new games a lot more than Elite.

The Beyond has a clear roadmap and its achieving it well, how Q4 turns out will be important for player confidence but if this year works then I can see it being a good future format.


They don't want to talk about stuff until they know they can deliver, as multicrew was obviously amazing hard to get out the door but they had stated it as an update. So if we get used to yearly roadmaps with a direction, but enough vagueness to allow the devs to be creative but also realistic, then I think it will work.

This year is an important year for player confidence but I think its gonna be good an then we will get another roadmap maybe for next year.

 

[lenna]

Mythical Man Month is talking about the specific case where you're halfway through a project planned to take N programmers X months, realise you're behind schedule, and try to fix that by adding more programmers.

The general rule also applies when revising project plans from the outset - double the workforce does not necessarily result in double the productivity and in practice the larger the work force the lower the cost efficiency.

Not everything can be time compressed and typically it involves cutting corners to at least some degree - that in turn can result in increased project risk and reduction in quality of output (even when done carefully). If the work force can be split into effective and smaller teams working on independent parts of the product then the productivity impact of a larger work force on a given project can be mitigated to a point.

As a general rule of thumb though double the workforce does not equate to double the productivity, and there are some things that will take at least X time regardless of the number of people you throw at the problem.