Sounds like you encountered what I call an "Uh-O Architecture". It's basically OO but overdone. Too many classes, too fine-grained, too abstract, too many layers, too many designer patterns for the sake of design patterns, etc.

I like that! I'm appropriating that term!

It's not you; it's a case of objectionably-oriented programming:

http://en.wikipedia.org/wiki/Spaghetti_code#Related_terms

> So the only way I can understand what the code is doing is by stepping through it in a debugger.

If methods are factored and named well, the name tells you what it does and you shouldn't have to look at the implementation unless its not doing what it says.

I've found that good OO programs are understood by understanding the classes and messages between them, not by reading the implementations of those methods. Look for the big picture, not the details.

Sounds you are being hit with hard end of the OO code stick or Java.

I've been working with Zend Framework 2 (PHP) and it has a ServiceManager class that loads everything, but the configurations can be done in three different ways and it supports aliases and other things that make it really freaking hard to find out where a class came from. It's a huge learning curve. I understand using DI to make code testable but it also seems to make it a lot harder to follow.

Yeah, the 'correct' way of DI, etc. is actually a complete recipe for disaster when it's overdone.

As it looks like you're using .Net, you might want to look into resharper as it implements a 'go to implementation' as well as a 'go to declaration':

http://www.jetbrains.com/resharper/webhelp/Navigation_and_Se...