I once "inherited" a project where I counted more than thirty levels between the web pages and the send/receive on a queue to the system that actually did the work.

Funnily enough they had a huge team (and over 30 thousand classes) and a lot of time (over two years) but they couldn't finish it.

Edit: Should have said it was J2EE rather than .Net

I agree. I've spent the past 6-9 months cleaning up a .NET MVC project and one of the first things I did was to rip out all interfaces that weren't being used the way I expect interfaces to be used.

We have the base MVC project that references services for DI. We load in another DLL via Ninject to add customization on top of those services (custom parsing of some magnetic card swipes for different institutions we deploy to and such). I discovered that while all of our services (~20) had an interface, only one of them was being customized/overridden. This mean that in order to do something as simple as a parameter change, it had to be changed in way too many places: the definition, the implementation, and the usages.

Why have that extra layer? If we need to override in the future, we can add more interfaces. For now, I just want to maintain my sanity.

I am seeing it all the time when consulting for companies. Their developers just love taking relatively small things and turning it into multilayered monster with insane amount of dependencies for code, development building pipelines and deployment.

I see that too - but I also see plenty of completely un-testable code, because the controller constantly reads from AppSettings, or creates a new database connection directly, or similar issues.

For small applications, instead of going full on DI, I sometimes just make a few simple public static properties, that I initialize on program startup. Then you can initialize them differently in your test harness. This is a lot easier to understand if you're not an expert in the chosen DI framework or app framework.

I am designing financial software for the crypto industry and I definitely prefer the ability to 1) have a high test coverage, and 2) quickly be able to write regression tests. Without dependency injection with mockable objects, that would not be possible.

Probably not but it is in my opinion very nice to have the ability to mock evertyhing if and when you need it.

You always have the ability. It's just writing code. But you should only do it when you need to.