How many programmers are working on ED?

300 people consider even administrative Personal which is not working on ed
No one has never Said they do nothing : quite the opposite.

The technician are on work but are less than 300

And they have 3 project : one main which is jurassic; the others are :coster an ed

Jurassic should take the main resources let say 150 people
Let s suppose they have 50 administrative staff we have 100 more people
Add 2 project and we have 50 people fo each.

And no: i did t see Fd tell us how many people are working on Elite as proved by the fact that a person from the staff has posted here not answer ing the question .

Drop your +5 sword white Knight sometimes : it would help you to see the things on a different perspective

About the other user asking what feature removed there was a post from dev where they were interested in adding a s cientific personal gunner and pilot

And but i could be wrong here it seems to me even NPC multycrew

Umm... actually, they have more than 3 projects. Some of their older games are still being supported, and they recently released a DLC or update for erm... Zoo Tycoon i think?

Perhaps though, after all these posts, and since FD are not answering, how many programmers do you think FD need working on ED?
 
In the end... why does this even matter, and why do a few people seem to feel somewhat entitled to get a census of FD's human resources?
 
I think the reason people are asking is because "How many programmers working on ED are required to fix a bug?"

Well, I won't ask *which* bug you mean Old Duck :)

IMO a tough question to answer because I would imagine that much of the core functionality is cross-product. E.g. the Cobra engine is used for ED and PC. There is probably a separate team doing engine development that affects all products. And different teams again working on the various ports? Just a guess based on how things are done at places I've worked in.
 
Last edited:
Umm... actually, they have more than 3 projects. Some of their older games are still being supported, and they recently released a DLC or update for erm... Zoo Tycoon i think?

Perhaps though, after all these posts, and since FD are not answering, how many programmers do you think FD need working on ED?

That's the question : i am not a Dev i don t know the code so I have no idea.

Neirher do I have ( as consumer ).

But I would truly be pleased if FD would come here saying : at this time and during horizon have worked on Elite the same number of people that worked on it from 1/1/2015 to 31/12/2015

When that Company was able to fullfill the 1. Expansion while delivering the first 2.0 in 1 year and not in 3 years ( almost)

But I fear they will not answer in that way ( if ever they ll do).

Also the question was quite straight : there is no need to define the kind of programmer working on Elite ( Graphic coder or animation )
The OP was intersted in knowing how many Tech are working on ed : Period.

And that question - you like it or not - is still waiting for an answer


( my last 3 post on mobile)
 
Have any of you guys read one of the bibles of software development, The Mythical Man-Month? If so, you'll know that throwing more developers at a problem often makes it worse. The analogy that is often used is that 9 women can't make a baby in one month. Development on a large project is all about communication and cooperation. A small, committed and focused team is much more productive than a huge assembly line.

This is, in essence Brooks Law:

  • It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.

  • Communication overheads increase as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.

  • Limited divisibility of tasks. Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration (up to the point where additional workers get in each other's way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, "nine women can't make a baby in one month".
 
Have any of you guys read one of the bibles of software development, The Mythical Man-Month? If so, you'll know that throwing more developers at a problem often makes it worse.

Yes, I've read the book. I agree with the overall premise, but not the "making a baby" analogy. If only one person was 100% responsible for making ED, all of us would be shouting, "Hire more people!" I think a much better analogy is the aerodynamic drag curve:

Power_curve_2.png


I would also argue that the advent of object-oriented programming shifts that "sweet spot" to the right (as in, it allows more people to work on a project before it bogs down).
 
But I would truly be pleased if FD would come here saying : at this time and during horizon have worked on Elite the same number of people that worked on it from 1/1/2015 to 31/12/2015

That's not likely something they can say. Its likely that the number of people working on ED changes from month to month. When you have multiple projects on the go you shift resources around as you need them.

I'm guessing what you and Old Duck are more interested in knowing is if FD are still committing a reasonable amount of resources to developing the game and that its still a high priority for FD. Would that be a reasonable interpretation of what you want to really know? After all, tech/programmer numbers don't really tell the full story.

In which case, i refer you to Dale's post from a couple of weeks ago:

"Is FD slowly shifting focus away from ED?"

The short answer: No.

The long answer: No, we're not.

Devs leaving the project: People move around and change teams, this is called career development and growth and should be encouraged. We then bring someone in to replace them! This doesn't affect the development process because no single person informs the development of the game completely. I would say David has the most influence but instead of dictating the course and direction of the game he works alongside (in the literal sense of actually foregoing his own office to be sat with them and get involved in ideation and decision-making processes as a team) the designers, animators, programmers, audio teams, etc. I would say that it's actually the opposite feeling overall. Focus is higher on ED. We have ambitions, we have the beginnings of a roadmap, and the dev/design team are holding more meetings and planning sessions than I've seen previously in my two years here. This is something that the community have asked for and to do right by you we're putting extra time into the planning process.

So... no. We're not shifting focus away.

Either take that at face value or not. Up to you. But that's about the strongest statement i suspect you will get on this topic.
 
That's not likely something they can say. Its likely that the number of people working on ED changes from month to month. When you have multiple projects on the go you shift resources around as you need them.

I'm guessing what you and Old Duck are more interested in knowing is if FD are still committing a reasonable amount of resources to developing the game and that its still a high priority for FD. Would that be a reasonable interpretation of what you want to really know? After all, tech/programmer numbers don't really tell the full story.

In which case, i refer you to Dale's post from a couple of weeks ago:



Either take that at face value or not. Up to you. But that's about the strongest statement i suspect you will get on this topic.

And they say it here. However, no matter how much evidence is provided, the naysayers and those with an agenda will continue to push the "Elite Dangerous is doomed" line.
 
That's the question : i am not a Dev i don t know the code so I have no idea.

Neirher do I have ( as consumer ).

But I would truly be pleased if FD would come here saying : at this time and during horizon have worked on Elite the same number of people that worked on it from 1/1/2015 to 31/12/2015

When that Company was able to fullfill the 1. Expansion while delivering the first 2.0 in 1 year and not in 3 years ( almost)

But I fear they will not answer in that way ( if ever they ll do).

Also the question was quite straight : there is no need to define the kind of programmer working on Elite ( Graphic coder or animation )
The OP was intersted in knowing how many Tech are working on ed : Period.

And that question - you like it or not - is still waiting for an answer


( my last 3 post on mobile)

They said that they have more people working on ED then they ever had before on the Expo live stream. Maybe you should watch it if you haven't already.

Here is the link for you:

https://www.youtube.com/watch?v=5MYuX9vrP_o&feature=youtu.be&t=137
 
I'm guessing what you and Old Duck are more interested in knowing is if FD are still committing a reasonable amount of resources to developing the game and that its still a high priority for FD. Would that be a reasonable interpretation of what you want to really know?

I didn't write the OP as a parable or allegory - I asked a simple question, and a couple people pointed out that there is a "Credits" option in the main menu, which answers my question. While the "battle of the strawmen" that this thread has devolved into is somewhat entertaining, "what I really want to know" was answered back on page one.
 
Here is an example from the team I am currently responsible for. We manage 15 systems.

1 boss :)
1 Functional designer
2 programmers
2 (functional) testers
6 Functional controlers
i was with a software house a few years ago, making 3D cars as part of a vehicle recognition tool for the police.
our 3D team (modelers, texturers) was about the same size as the programming team. along with the roles you've already mentioned, there were also researchers, photographers and scanners, etc. - a few extra bodies required for making the 3D assets. so i imagine FD would have a whole bunch of their staff doing similar stuff.
 
Last edited:
Hey Duck, is this about the PS4 lod blurry texture pops since 2.4? They still haven't fixed it? Ah well, from what i've seen since 2.1, I'd say it takes months to half a year to fix a specific issue. So maybe by the beginning of 3.0 early next year, it'll finally get fixed. I think the FX17 video just showed a small segment of a development room. The complex is far bigger and there was a video by ObsidianAnt about his visit to FD where he was reassured plenty of staff were working on ED. Maybe if we could also see the credits list for Planet Coaster and see how many staff names are on both ED and PC lists, there could be an idea of how much of the staff gets utilized cross-project. I'd think not too many.
 
Last edited:
Hey Duck, is this about the PS4 lod blurry texture pops since 2.4? They still haven't fixed it? Ah well, from what i've seen since 2.1, I'd say it takes months to half a year to fix a specific issue. So maybe by the beginning of 3.0 early next year, it'll finally get fixed.

That's the tip of the spear, the "why" behind the question, yes. The Return (2.4) has been plagued with bugs, and the patches aren't fixing things, they're breaking other things.. Having spent some years in software development, the answer to my original question (along with other observations) allows me to draw my own conclusions regarding the "deeper questions" I have.
 
Last edited:
Elite Dangerous already does include pay-to-win... as is obvious to anyone who has ever won a fight between a RNGineered ship and a plain one.

err, that's play to win, not pay to win. You cannot buy engineered upgrades from the Frontier store for cash. Don't confuse gameplay and DLC.

Also the number of programmers on Elite at any one time is not necessarily a critical factor. For example, modellers, animators and texture designers create ships - these are then added to the game engine using the existing framework - zero programming involved, yet considerable content.

It is absurd how people are making declarations on the "correct" number of programmers to undertake a project of which they know absolutely nothing. Nobody outside Frontier does. It may well be the currently programming workload is handled easily by two people, but since I'm not Sandro, I can't make that call.
 
Have any of you guys read one of the bibles of software development, The Mythical Man-Month? If so, you'll know that throwing more developers at a problem often makes it worse. The analogy that is often used is that 9 women can't make a baby in one month. Development on a large project is all about communication and cooperation. A small, committed and focused team is much more productive than a huge assembly line.

This is, in essence Brooks Law:

  • It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
  • Communication overheads increase as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
  • Limited divisibility of tasks. Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration (up to the point where additional workers get in each other's way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, "nine women can't make a baby in one month".

Excellent post. Those who have no experience of software development have little idea of the realities and complexity of these projects.

Number of X (be it programmers or what ever) working on a project is a terrible metric of productivity. It can also be used to bamboozle those who don't understand how the project team works. I've worked at places where the manipulation of job titles and hours dedicated to specific tasks were used to justify costs to naive customers.

The different skills required and the team balance will also change a great deal over the lifetime of a product. This is especially the case in multi-year and continued development of live products. Hopefully, basic architecture work and cores systems are well developed early on reducing the need for certain specialist involvement later in the product life-cycle. Tools programming helps to automate certain tasks allowing efficient use of specialist skills later in development. Good management and the use of effective workflows can have a dramatic effect on the productivity skilled specialists. In a successful professional environment they way project teams work and are resourced will be continually revised to get the best bang for the buck.

It's also smart to avoid re-inventing the wheel, where it isn't cost effective, and license technologies and service from others. Check out Dav Stott's presentation on ED server infrastructure to get an idea of the breadth of licensed technologies and services used just for the server side of things. Does Frontier have a dedicated team building text to speech from scratch for Galnet Audio? Looks very much to me like they will be using Amazon Polly or a similar service.

TL/DR Headcount is a terrible metric for judging development progress.
 
Back
Top Bottom