Craig Castelaz's Blog

Hesitant Acrobats

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/J2EE’s 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, he’s the guy who’s 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 doesn’t want to be held responsible for code he can’t 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, I’m 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.

Comments

• Yes! ... NO! ... I mean yes?
  What an interesting entry Craig!

  I found myself going from agreeing with you, to disagreeing, and back to agreeing.

  I believe that as with all areas of science; it simply is not practical to senselessly dig deep into the low-level details. There is a far greater importance on extension of the technology.

  However, if there is a serious problem in the technology, it should not be worked around; we might be on the wrong path. This demands investigation! Right?

  Yet indecision can be an opiate; right? Therefore we must push ahead; no looking back!

  A lot of time gets wasted, especially by novice developers; those who must review all the details of perfectly working systems, before beginning to use them. Hopefully they learn from this; both the architecture of well-designed systems, and the wastefulness of the activity itself.

  Yet the most phenomenal developers I've ever had the pleasure to meet were so extremely productive because they abjectly refused to investigate the details. They faithfully leveraged what existed, and quickly advanced the state of the art.

  So I forgot: was I with ya; or agin' ya?

  Posted by: cajo on July 21, 2004 at 01:52 PM

• Are we too self-absorbed?
  Good article (and cool illustration!)

  I recently heard Bruce give his talk in Austin, and the techno-weenie in me was captivated by the concept of a smoother running engine under-the-hood. I think the ideas incorporated in Spring/Hibernate/EJB 3/etc. are great... but they need to be kept in context.

  The big problems of society that software could help solve aren't really waiting on a better implementation of object persistence.

  I'm all in favor for tuning the engine, but surely the car is in good enough shape to take a road trip or two.

  Posted by: johnreynolds on July 22, 2004 at 12:25 AM

• Yes! ... NO! ... I mean yes?
  To be real truthful, I'm not sure if I agree or disagree with it myself. Perhaps we should treat it as a cautionary tale, and leave it go at that.

  Craig

  Posted by: castelaz on July 22, 2004 at 03:15 AM

• Are we too self-absorbed?
  I hadn't thought about it in terms of self-absorption, but you may have something there. I know a number of programmers who will happily rework code again-and-again because they see a better way. They're clearly entranced by the dance of details.

  Craig
  

  Posted by: castelaz on July 22, 2004 at 03:35 AM

• spring hibernate
  To me the whole point is moot. Because I was just so much more productive than a team that used old fashoned ejb that it was beyond a joke. If I spent the next year persuading them to use spring and hibernate or ibatis. We would all deliver more software together in the following month. There were just so many of them and they just performed so bad compared to us. Even in my wildest dreams I don't think I can be better than a hundred men. But if two men can deliver the same piece of software that this large a team can fail on given the same time something is broken badly. The build system alone that they had was more complex and sophisticated than the target software. I have seen it too where the mock objects test system is more complex than the target software. For me just use spring and write the customers software. All the projects these days seem to be destroyed but some nuts OO or ejb fantasy island.

  Posted by: robcresswell on July 24, 2004 at 10:30 AM

• RE: Yes! ... NO! ... I mean yes?
  Frankly, people who don't dive into the details of an implementation they are using scare me.

  Who can really use something they don't understand?

  People who blindly build on top of things they don't understand can't appreciate what they are using, nor are they likely to be able to fix things when they break. What use are they then? They wouldn't even be aware of the types of pitfalls that may exist and code themselves right into a hole they won't be capable of pulling themselves out of.

  All that being said, how far into a system you go, and how long you spend doing it are the 2 pitfalls of digging into something that's already been built. It's tough to balance them against making forward progress. I'm not necessarily advocating knowledge at a level that the implementation in question be reproducible.... unless that level of detail were required. sometimes it is.

  .... I guess I'm just tired of running across "programmers" that barely understand more than they read in a book and worse: have no desire and no ability to dig a little deeper to gain an understanding and appreciation for what they are using...... and people wonder why there is so much bloated code in use...... "phenomenal developers", right.

  Posted by: nmaynard on July 25, 2004 at 11:26 PM

This work is licensed under a Creative Commons License.