This morning, as usual, I listened to Morning Edition on the way to work. Bob Edwards was interviewing a Norwegian singer named Sissel about the release of her first U.S. album. Sissel has sold a lot of albums in Europe, but is virtually unknown here. (Selling a lot of albums doesn’t necessarily impress me, but touring with The Chieftains does, and what I heard of her music this morning sounded pleasantly accomplished and eclectic.)

She spoke about one of the songs on her album, “Lær Meg Å Kjenne,” which is an old Norwegian hymn. Translated, the title means “Teach me to see your pathways.” The story behind the hymn is of a man coming home from a pilgrimage to find his house burned down and his family killed. He falls to his knees, and the hymn is his prayer.

Bob Edwards said, “And you sang this at a wedding?”

Sissel replied, “Well, yes—it’s a song of trust, of knowing that there’s a plan.”

From what I heard of the song, I’m with Sissel. A wedding is joyful, of course, but the joy comes from the binding of two lives together, as much to stand by each other through the hard times as to share the joys of the good times. In a ceremony that contains the words “for better or for worse, for richer or for poorer, in sickness and in health, ‘til death do us part,” a song like “Lær Meg Å Kjenne” has a place.

There’s an English hymn with a similar history. In 1873, Horatio G. Spafford received word that his family had been lost in a shipwreck. His response? The magnificent hymn “It Is Well With My Soul.” There is certainly sadness in it, but also calm assurance, as well as triumphant joy:

My sin—oh, the bliss of this glorious thought—
My sin, not in part, but the whole
Is nailed to the cross, and I bear it no more.
Praise the Lord! Praise the Lord, oh, my soul!

It’s no surprise that poor marketing can really hurt a product. Today I saw a perfect example of how too much marketing can hurt a product.

I’ve known about JMX for at least three years—probably four. Several times in the past few years, I’ve had a few minutes of spare time, and gone to check out JMX. What did I find? Marketing-speak. Too much hype, too many claims, not enough technical substance for me to understand what JMX really was. In each case, I came away wondering if there was really any there there.

I have a background in system and network management software, so it’s not like JMX should be difficult for me to understand. But the overview documentation was always too fluffy to tell me anything in the short bits of time I had available, and I didn’t have time to go dig into the spec. So I always came away unconvinced. I was nearly convinced that there really wasn’t anything worthwhile in JMX when all of a sudden I started hearing the JBoss folks raving about JMX. That piqued my interest again, because those guys are very smart.

I’m at the Great Lakes Software Symposium this weekend, and Oliver Schmelzle of Covasoft gave me a short overview of JMX. I got it in about three slides. It’s simple. Extremely simple. And it’s real, and it’s useful, and I can see why JBoss is using it.

The really frustrating thing about the JMX marketing fluff is that the people who are likely to grasp and recommend the use of JMX are techies—the kind of people who respond to example code and scenarios, not extravagant claims. Oliver agreed with me that JMX’s big problem is that most of the people who should be interested in it don’t get it. And the reason is because it’s been marketed nearly to death.

I don’t really have that dim a view of specialization, but I do believe the software industry values specialists too much. For many of the same reasons that general-purpose programming tools are better than specialized ones, developers with broad experience and knowledge are more valuable than specialists in most cases.

At the Rocky Mountain Software Symposium a few weeks ago, an attendee said something like “All this stuff about broadening yourself sounds good, but companies want to hire specialists, not generalists.” Sad to say, he’s right, but there’s a related fact that’s just as important: companies may not want to hire generalists, but they certainly like to employ them. That is, if you can convince them to hire you, you’ll have better than average job security.

(For a darkly humorous take on this, read Anne Learns to Recruit. And it’s also worth checking out the page on this topic at Ward’s wiki.)

Well, maybe not perfect, but close.

Michael has added a feature I asked for: a “recent links” panel. Here’s a picture. I’ve been trying to find time to start working on that myself, but Michael beat me to it.

I can’t wait to start using it!

I read Mike Clark’s Wag your EJB comments and James Duncan Davidson’s Listen to the EJBs go Pop response shortly after last week’s Pragmatic Practitioners meeting here in Dallas. And something clicked. (It should have been obvious from the beginning, I suppose, but brains work in funny ways.) Mike’s comments are about how to deal with EJBs, and ask “where did we go wrong?” Duncan tried to answer that question in the context of EJB history. My goal here is to try to draw lessons that we can apply to other technology choices.

The meeting Tuesday night was a discussion of tools, and Dave started it off with the following intentionally provocative statement: “It is impossible to do quality software engineering with an IDE.” Of course, there were a few people who took issue with that, but we quickly converged on something we could all agree on: while IDEs offer a lot of useful tools, you should never allow the IDE to shape your project. The project should assume its natural shape, and the tools should support that. We also agreed that the fastest way to go down the wrong path in that regard is to let the IDE handle builds.

The problem, of course, is that IDEs tend to impose a particular view of project structure. And more often than not, they only support particular compilation tools. So if you want to build part of your system using another tool, or a custom code generator, that part of your build can’t be automated by the IDE. So you have to make a choice between automation and the natural technologies for developing your system. You can’t win unless you take the build process away from the IDE and use a more general-purpose tool.

There’s always a tradeoff between special-purpose and general-purpose tools. Special-purpose tools can make life a lot easier when your needs match what they were designed for, but they aren’t easily adapted to other situations. General-purpose tools are never quite as easy as a specialized tool at its best, but they’re life savers when you’re thrown a curve ball.

I think the choice between specialization and generality is particularly important for software development. Part of this is because even software projects that seem superficially similar tend to differ in many surprising respects. (In other words, software projects nearly always throw you a curve ball.) Additionally, there is the problem that we still don’t understand software development very well in any fundamental sense, so folks building specialized tools often make mistakes when deciding where to restrict flexibility. (Another of Duncan’s recent blog entries aims straight at this, and scores a bullseye—I don’t know how many copies of that Gosling paper I’ve printed and given to clients over the past few years.)

A great example of the way seemingly benign restrictions can bite you later is make. That program is shockingly general, at least if you measure that by the number of uses to which it’s been put that the designer never envisioned. But it has one unfortunate limitation—a bias toward operations within a single directory—that renders it a poor choice for a task very close to its design center: building Java programs.

As Duncan points out, EJBs were designed for very narrow problems, and might be very good for those problems. (I’m not so sure even that’s true, but that’s another argument.) But they enforce a very narrow, specialized programming model. No threads. No … well, no lots of things. You give up a lot to program in an EJB container, and that might be worth it if your problems are close enough to EJB’s strengths that you really get a lot in return. But as Mike points out, most systems are warped by EJBs, without seeing any compensating benefit.

It’s instructive to contrast EJBs with the other core element of J2EE: servlets. Within the externally imposed constraints of the request/response style of HTTP, they are nearly as general-purpose as you can get. “Here’s the request: deal with it and get back to me with a response.” There are a lot of other things that servlet containers can do for a servlet, but the servlet has to ask. And by comparison with EJBs, servlets are broadly applicable and extremely successful. (After that exercise, if you want to get depressed, think about the technology that was sacrificed on the EJB altar: Jini.)

When looking at a software development technology, favor generality over specialized tools that claim to make things easy. Unless the tool is aimed at a very well understood domain, and your system is squarely within that domain, chances are you’ll regret going the special-purpose route.