Just A General Question, How Do Multiple Programmers Work On The Same App?

General Discussion & Community Support General Discussion
1

This is question I’ve had for a long time. When you have a very complex piece of software such as our sim, how do they organize their work and objectives with many people writing their code on a common piece of software? Maintaining Change Management in its self has to be a bear!

Just trying to understand again from a big picture of things, how development management is accomplished with many programmers working simultaneously from different aspects of the overall sim software.

Always wanted to know…:grinning:

1 Like
2

Branching (version control) - Wikipedia

Have a look over there.

2 Likes
3

Google SCRUM.

1 Like
4

There’s Team solutions like Visual Studio Team Services, which helps to organize team coding and collaboration. It also able to handle nicely Git repositories. Also Cloud aware with Azure DevOps. Many parts helps making decision on conflicting coding.

2 Likes
5

BIg projects are divided into subsystems, with the interfaces between them carefully worked out. Then they can be (largely) coded and tested independently.

3 Likes
6

Devops is the overarching concept for managing software development (from small to gigundously-large projects like FS2020), with the aforementioned branching strategy as a key component to this.

2 Likes
7

Large projects like Microsoft Flight Simulator have multiple teams working on multiple different areas simultaneously. For example, we have a group of devs who are responsible for fixing bugs with the graphics rendering engine while also improving it by adding new features like DX12 and DLSS support. Then there are entirely different teams responsible for other parts of the product like the weather system, the flight model and aerodynamics system, the user interface, avionics, the SDK (tools for 3rd Party devs to make addons/mods), the Marketplace, and so much more. There is very little overlap between work being done by each individual group, so they can typically make changes to their code without impacting the work being done by other teams.

When preparing for a new build, each team is tasked with meeting certain deliverables and milestones defined by their managers/producers. After a certain point, all code changes are locked and merged into a new build. We then have our internal QA team complete a first pass of testing the new build to make sure there are no critical show-stopping errors, bugs, and other issues that might have cropped up during the code merge. For example, it’s possible that a change the Weather team made could have inadvertently caused a bug to a completely separate change the Flight Model team made. For large builds like a new Sim Update (e.g. the upcoming SU10), we then make it available as an opt-in beta test to any player who would like to assist the devs. The ability of thousands of players each using MSFS in different ways to identify issues obviously exceeds the capacity of our own internal testing team, so these public beta tests are invaluable to the devs.

In the past, we’ve run each beta test for a period of ~2-4 weeks. If you’ve seen any of the recent media interviews with Jorg where he discussed this topic, he mentioned that he wants to lengthen the period new builds are in public testing to give the community more time to identify issues and the dev team more time to resolve them.

8 Likes
8

Thanks to all for the references and great explanations you took the time to provide. You gave me a MUCH better understanding of a complex subject! The orchestration that has to happen for all of this work is amazing!

3 Likes
9

I commend you for asking. :+1:

Being a software developer myself, I find it mildly annoying to find thread after thread here where people - often with zero knowledge about how software is built and maintained - vent their baseless opinions about what Asobo should be doing differently.

6 Likes
10

Thanks for that explanation. Based on the issues intruduced with each update, something in that process must not be working as expected.

Maybe the extended BETA periods will overcome the historical cycle. I am hopeful.

11

Git („source code version control system“), SCRUM („(self-)organisation of development teams and their member roles“), agile development…

All those thing are just tools to get your software engineering job done.

But the essential - and price-winning - question of the OP remains: „How do you master the complexity of a complex topic like flight simulation, weather simulation, graphics/effects, AI traffic, multiplayer, development SDK, … - and make all this stuff - and in the end the teams & people - work together?“

And the answer to that is at least 2000 years old and so was already known to the Romans (*):

„DIVIDE ET IMPERA!“ - „Divide & Conquer“.

Applied to software engineering this means that you cut the problem at hand into finer-granular pieces - e.g. „weather“, „aircraft“, „airports“, „grapics“ - and rinse and repeat („clouds“, „rain“, „online weather“, „cockpit“, „ILS“, …), until each problem description can be explained and understood by a single person (that doesn‘t necessarily have to be a software engineer herself, but rather a „subject matter expert“).

Once such a „work item“ is understood (understandable) by a team and an „overall architecture“ has been laid out (which - most importantly - also defines the „hierarchy“ of those „items“ and how they interact with each other) those items are then essentially translated into a technical specification - or „code“ in the end.

Another important principle is „keep it as simple as possible, but not simpler“. But this principle is most often forgotten in software engineering and shall be a topic for another time :wink:

(*) As I had later learned after my studies „divide & impera“ actually meant - historically - that the Romans tried to split their enemies (mostly in the north) into smaller territories, in the hope to accelerate/spread rivalries among those people, such that they would be busy fighting each other instead of trying a „collective uprise“ against the Romans themselves.

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.