Simple is a seductive notion. We all want to make things simple. But when we talk about software, simple could mean at least two different things.

There are always two ways of looking at nontrivial software: the implementation view, and the user view. I have always gotten the impression (I may be wrong) that many people who say that J2EE is too complex confuse the second view for the first. So, just in case I'm right about this, I think we should rephrase. Perhaps we should say J2EE is too /inconvenient/.

A simple framework is very often /not/ the best solution to a difficult problem. Making life easy for developers does not mean giving us simple tools. The problem with J2EE development is not that the J2EE stack provides too much complex functionality; it is that the functionality is not exposed to the user in a convenient way.

For example, Hibernate is /much/ more complex (implementation-wise) than a CMP 2.1 entity bean container. Arguably, some of Hibernate's user-visible functionality is also more complex. For example, HQL has many more features than EJBQL and could therefore be said to be more complex. Likewise, Hibernate's support for multiple inheritance mapping strategies is a complex feature, not visible in CMP 2.1.

But it is that very complexity that makes Hibernate powerful, and, perhaps paradoxically, simplifies life for people using Hibernate to write applications. By contrast, CMP 2.1 is simultaneously too simple (featurewise) and too complex (from the point of view of the user).

The best frameworks are /powerful/, not simple. But they do try to get their internal complexity out of the face of the user, as far as possible. Sometimes it is possible, other times not. If you try to oversimplify a difficult problem, you end up making life more difficult for your users, who are then forced to work around your framework's limitations, instead of working with it.

There are very, very few simple solutions to difficult problems. Be very sceptical when someone claims to have found one.

30. Jul 2004, 05:00 CET | Link
I would add that frameworks must anticipate what their clients (users) are trying to accomplish. Much of the problem with EJB seems to be the confusion over what service(s) the container providers: is it a persistence framework? a distributed object framework? both?

Keeping a framework focused helps to minimize its complexity while exposing the right interface to its target audience.

04. Nov 2004, 23:51 CET | Link
I think that Richard Gabriel's "worse is better" essay does a good job of dissecting the underlying differences of approach and aesthetic.
19. Sep 2008, 07:02 CET | Link

no, what we should always be looking for is powerful and simple tools/frameworks etc... it the basis of the computing science concept of elegance!

so, given your example of using hibernate... simple? yes... complex? definitely... but i can use simple sql to get all the data i want from a relational persistence layer... sql is powerful and simple! i'd say something is wrong with using hibernate!