IMHO the problem is that the people using them (developer’s but especially projectmanagers) did NOT change over time!

Let’s assume at 1990 (technologies and user-expectaions) it took one developer to get “enough” experience with every technology/practice/technique/methodology about 2-3 years.

In the year 2010 with probably 10 times more stuff to master and way higher user-expectaions this timeframe is now probably at 6-9 years!

Long story short:
IMHO its not the frameworks that get out of hand but we, the developers, have to find a way to catch up!
Maybe the industry needs to change it’s mindset that 2-3 junior-dev’s, 1 dev, 1 senior-dev and 1 PM could handle any project…

Or we just need more developers without a social-life and learning all the stuff at weekends. :)

It’s kind of a love/hate thing. Hibernate proxies, AOP, Scala implicits, Groovy MOP, … – it’s all so great when it works, it’s not so bad when it fails and you understand it, but it’s a mess when it fails and you don’t understand it.

You’ve got to be more like Merlin than Harry Potter to get it right.

1. Diving deep into the underlying framework to understand what happens beneath.
2. Trying lots of different paths to make the code work.

Both options are very unproductive and usually frustrating. Worse, the programmer cannot make a good estimate on how long it will take to overcome the problem. It may take one week or just 5 minutes.

On all new code I much prefer iBATIS, JDBCTemplate or even JDBC directly. The small costs to write the queries more than pays for itself by reduced complexity and easier debugging.

“[..] inside my favorite ORM to see how i works and learned how i should really use it, i’s been fine since then.”

100% ack. One needs to learn how the ORM works if you want to use it. Many developers don’t do that.

Redis is in-memory only. Looking at some memory graphs in operations if fear mem-only apps – seeing the JVM heap grow and grow +g+

But mem-only is the future I assume. I think about a post.

I try to reduce ‘magic’ in my own projects and only use it when it’s a real benefit.

I used to utilize ‘magic’ just for less important, ‘nice-to-have’ features. But it made it much more difficult to find out the cause when it broke.

After all I am very curious to someday read something about big in-memory web applications from you. With enough local memory the magic required to do an architecture like that seems much smaller. You should become a fan of that. Though you might not deem it applicable yet for your purpose :-)

a.) read the definition of magic again
b.) with non-deterministic input, output is non-deterministic either. Same goes for runtime behaviour
c.) non-linear behaviour is most often determenistic