devRant - A fun community for developers to connect over code, tech & life as a programmer

Hi there!

I've been worrying about the following problem for months now and I don't find any solution. Maybe anybody of you can lead me the way.

We are developing a software suite which consists of a number of desktop applications:

* 12 applications written in C++; all over 20 years old; further development by 5 or 6 guys (one man armys) - mainly bugfixing, changes of law implementations, small features
* 2 applications we are currently writing in C#; completely new developments of existing C++ applications; scrum teams with at least 5 guys; this is, where we put our focus in

These applications (C++ and C#) are sharing some core assemblies and are interacting with each other. So they are not independent.

We organize them in a mono repository in one huge solution, which consists currently of about 500 projects.

Advantages:

* With all projects in one solution and through project references, Visual Studio takes care of the right build order
* Code navigation is superb - every single line of code is accessible - this makes refactoring easy
* Every developer can map the branch and build the whole suite locally
* Debugging on the local machine is easy
* DevOps pipeline is straight forward - it just have to build a single solution

Disadvantages:

* The huge solution is extremely slow.
* If you want to build the solution or you want to debug (which does essentially the same as a pre step) Visual Studio is building a lot of projects, although they haven't been changed. Their detection is buggy. So sometimes you wait 2 minutes until it starts the app. That slows us down a lot.
* Full builds need about an hour, because its building the same projects (even if they haven't been changed) over and over again (with ready made nuget packages this could be improved a lot I think)
* If a core team member changes some core apis, he is changing the calling code too, although he doesn't know the calling code, because another team has written it. I don't think, that's best practice and it doesn't scale.
* Often, a C# developer has to mess around with C++ building problems, because the C++ projects are in the same solution
* It gets more and more confusing and frustrating, because there is no clear organizational seperation between apps and nobody can't just focus on his app alone.

Idea:

I was thinking about putting the whole framework and core projects in a new solution (around 100 projects). Then we could take all old C++ projects and put them also in a new solution (around 200 projects). This would leave the newer projects (new applications - C#) in the existing solution.

This should speed up things, and would be a first step to better seperation, BUT:

How should the integration process look like?

Scenario: Core team is changing an API in our framework

Current process: Because all projects are in the same solution, they change the calling code too. So it's immediately integrated and the app developers just have to do "get latest".

New process (?): Core team is providing the changes through a nuget package (new version). So does every developer now has to keep track of if there is a new package version and if yes, do the integration? And how can we coordinate the different teams, so they are upgrading all at the same time? Because we ship our applications as a suite, all apps has to use the same versions. Or should we automate the integration process? Is there a best practice?

I have to add, that our core team is making changes very frequently, so the integration process will have to happen often.

Any ideas/feedback/inspiration?

Thank you so much in advance!