>Tasks that used to take 5-10 files can now take 70-100!

This is a lie. The tasks never took only 5-10 files.

You are not solving any tasks with less than 10 files. Why? Because you're using C#. C# is a high level language. You are using more than 10 files just to create hello world.

Oh sure you don't notice them because you didn't write them. So you don't look in them. You trust them.

The problem isn't the number of files. It's that you now have so much going on that you don't trust.

So figure out how to make those tests work to the point that once they pass you trust these files the way you trust the files in .NET. Doing that is the point of unit testing. No one cares about the number of files. They care about the number of things they can't trust. 

>For small to medium size applications, SOLID is a super easy sell. Everyone sees the benefit and ease of maintainability. However, they're just not seeing a good value proposition for SOLID on very large scale applications.

Change is hard on very large scale applications no mater what you do. The best wisdom to apply here doesn't come from Uncle Bob. It comes from Michael Feathers in his book Working Effectively with Legacy Code.

Do not start a rewrite fest. The old code represents hard won knowledge. Tossing it out because it has problems and isn't expressed in new and improved paradigm X is just asking for a new set of problems and no hard won knowledge. 

Instead find ways to make testable your old untestable code (legacy code in Feathers speak). In this metaphor code is like a shirt. Large parts are joined at natural seams that can be undone to separate the code the way you'd remove the seams. Do this to allow you to attach test "sleeves" that let you isolate the rest of the code. Now when you create the test sleeves you have confidence in the sleeves because you did this with a working shirt. (ow, this metaphor is starting to hurt).

This idea flows from the assumption that, like in most shops, the only up to date requirements are in the working code. This lets you lock that down in tests that allow you to make changes to the proven working code without it losing every bit of it's proven working status. Now with this first wave of tests in place you can start making changes that make the "legacy" (untestable) code testable. You can be bold because the seams tests are backing you up by saying this is what it always did and the new tests show that your code actually does what you think it does.

What does any of this have to do with:

>Managing and organizing the massively increased number of classes after switching to SOLID?

Abstraction.

You can make me hate any code base with bad abstractions. A bad abstraction is something that makes me look inside. Don't surprise me when I look inside. Be pretty much what I expected. 

Give me a good name, readable tests (examples) that show how to use the interface, and organize it so I can find things and I wont care if we used 10, 100, or 1000 files.

You help me find things with good descriptive names. Put things with good names in things with good names. 

If you do all this right, you will abstract the files to where finishing a task has you only depending on 3 to 5 other files. The 70-100 files are still there. But they're hiding behind the 3 to 5. That only works if you trust the 3 to 5 to do that right.

So what you really need is the vocabulary to come up with good names for all these things and tests that people trust so they'll stop wading through everything. Without that you'd be making me crazy too.

@Delioth [makes a good point ](https://softwareengineering.stackexchange.com/questions/394399/managing-and-organizing-the-massively-increased-number-of-classes-after-switchin/394449?noredirect=1#comment868690_394449) about growing pains. When you're used to the dishes being in the cupboard above the dish washer it takes some getting used to them being above the breakfast bar. Makes some things harder. Makes some things easier. But it causes all kinds of nightmares if people don't agree where the dishes go. In a large code base the problem is you can only move some of the dishes at a time. So now you have dishes in two places. It's confusing. Makes it hard to trust that the dishes are where they're supposed to be. If you want to get past this though the only thing to do is keep moving the dishes. 

The problem with that is you'd really like to know if having the dishes over the breakfast bar is worth it before going through all this nonsense. Well for that all I can recommend is go camping.

When trying out a new paradigm for the first time the last place you should be applying it is in a large code base. This goes for every member of the team. No one should be taking it on faith that SOLID works, that OOP works, or that functional programming works. Every team member should get a chance to play with the new idea, whatever it is, in a toy project. It lets them see at least how it works. It lets them see what it doesn't do well. It lets them learn to do it right before they make a big mess.

Giving people a safe place to play will help them adopt new ideas and give them confidence that the dishes really could work in their new home.