Last week, Daniel Steinberg wrote that he attended a local JUG meeting to hear Bruce Tate speak about his book Better, Faster, Lighter Java. I was fortunate enough to be at the same meeting. Bruce's presentation was interesting, and sparked a fair amount of interaction between him and the audience. Of course, this made the time fly by all too quickly, but Bruce was still able to squeeze in a little time for questions and comments before he had to leave.
As Daniel noted in his blog, one of the comments at the end concerned EJB/J2EEs ability to address complex problems. Light-weight techologies are all well-and-good, but complex problems require complex solutions. And in a follow-up remark, the same person held that technologies like Hibernate simply shift complexity, they don't eliminate it. His belief is that it would take it him as long to feel competent with Hibernate as it took him to feel the same with EJBs.
Another set of the comments came from a person who identified himself as a maintenance programmer. When something breaks, hes the guy whos responsible for fixing it. In order to do that, he needs access to the code. His primary concern is that technologies such as Hibernate and Spring may hide too much. Hidden code is a barrier to him. He doesnt want to be held responsible for code he cant touch.
While I understand and sympathize with these concerns, I believe both sets of comments reflect an all too common desire by programmers to bury themselves in a morass of details. Of course, Im just as guilty as the rest. As I mentioned in my last blog, the first thing I did when I got an assignment to support digest authentication was to sniff the packets going to and from the secured web site. Now, how detail-centric is that?
One of the traits of a good programmer is a love of details. but there is a point where it simply gets in the way. Light-weight technologies like JDO, Hibernate, Pico, and Spring are designed to leverage reflection, code generation, and dependency injection. They're intended to not only introduce flexibility into a system, but to also relieve the programmer of a lot of mundane coding. You'll certainly want to dig a bit under the hood to see how they work, but detailed understanding is not required. If you spend too much time examining the giant's shoe size, you'll never have the time to actually climb up to his shoulders.