It's funny, the way your memory associates things.

As I was reading Loraine Lawson's post from last week about the wisdom of going after "low-hanging fruit," I could not stop thinking about one of my all-time favorite Warner Bros. cartoons, "Show Biz Bugs," from 1957.

Like I said, funny.

Like Loraine, I was briefly employed by Gartner after it purchased TechRepublic several years back (the site is now part of CBS Interactive). During that time, I was a director (seems we had more "directors" than actual employees and projects to direct), and one of my jobs was to chair a committee that reviewed and prioritized new development and business proposals.

I must have referred to "Show Biz Bugs" a hundred times during that (blessedly brief) time, and always in regard to proposals that attempted to justify an ongoing expense by how well it could perform in picking "low-hanging fruit."

My mantra went like this: Bugs and Daffy are vying for the love of a vaudeville audience, and of course Bugs is winning -- Daffy gets nothing but crickets as he hoofs his heart out. So finally, he dons a devil getup, douses himself with gasoline, and swallows a match. Boom! The audience loves it, and Bugs is the first to give his pal/arch-enemy a big hand, saying "That's terrific, Daffy! They loved it. They want more."

But as his recently departed spirit floats upward, Daffy laments: "I know, I know, but I can only do it once."

Low-hanging fruit is often a dangerous way to justify a new investment in tech, or anything else. Investments have to pay for themselves, after all, and in the case of large IT projects, that typically means scaling (another Gartner favoite) beyond their initial, most obvious and easiest payoff.

Certainly, when Judith Hurwitz speaks, you should listen, and Loraine's point about her interview with the respected analyst is well taken. However, in reading this quote from Hurwitz:

If they have been convinced that a service-oriented architecture is the way to go, they will begin by figuring out what business problems they can solve relatively quickly. They won’t try to sort of boil the ocean, doing a massive project that is going to take three years to show any results. They will start with something relatively confined that they can then come back to the business and say, 'See what we were able to do? Isn’t that helpful?' And the business will say, 'Wow, yeah, let’s do more.

I trust that in coming to the conviction that SOA is a good idea, IT has looked past initial "quick wins," as Loraine notes, and determined that, in fact, SOA does scale to be the right architectural solution for the enterprise. Either that, or the initial "low fruit" implementation of SOA has such an immediate impact on the bottom line that it can stand alone as a contained investment, whether or not the "architecture" part of equation scales out. That latter seems quite unlikely to me, but of course all I know about SOA I learned from reading Loraine's blog.

Obviously, fruitful low-hanging quick wins (I couldn't resist) are a great political tool for getting buy-in for an initiative, which is as essential to successfully pulling off major change as clean code and solid ROI calculations. (Again, I turn to Loraine for wisdom.) But long-term success also relies on often tedious, seldom fun analysis of how well the initiative will perform after you've garnered your applause for the quick successes you can't easily duplicate.