I'd say there is no upside for the complex invisible magic. Half the time you have to run the application and pray that the configuration beans you've placed are working and if not, you are pretty much in trouble. Perhaps you missed a step in adding a configuration decorator in your application or configuration class, or used some deprecated method or used some incorrect class in the class hierarchy for the bean you want to return.

it's not even magic, it's redundant over engineering at its peak

haskell has magic, but at least its concise..

It's like playing Where's Waldo, to find the actual code in an enterprise Java/C# application.

I think it's a fundamentally different mentality as far as the code. The codebase is so obfuscated that it might as well be binary data rather than plaintext files. You need an IDE to manipulate it efficiently.

I feel like Enterprise is all about looking complex to justify the fees. The simpler it looks the harder it is to bill.

http://jeffacubed.com/the-boilermaker-story-or-knowing-where...

But Spring gives you the best of both worlds. A lot of verbose code (as annotations and class inflation instead of explicit boilerplate) and inscrutable magic.

If only we could all agree on what "simple" means - a lot of "enterprise" code I've seen would sweep vast amounts of complexity into hard to spot places to that you could have a small thing that people could point at and say how simple the one visible bit was, ignoring the vast amount of complexity lurking under the surface somewhere and invoked by more or less magical means.

I disagree. The "boilerplate" is the boring stuff I don't want to waste my time with.

In my opinion software development is less about what specific developers want to spend their time on, and more about producing solid software.

Does not spending time on boilerplate improve the quality of software you produce? I find that it doesn't.