Russell Beattie

This comment from Cedric on his blog about my assertion that Sun needs to concentrate on the solution, not just the technology:

I disagree. I think the only thing that Sun is good at is precisely that: lay the foundations for technology. J2EE might be complicated, but it solves a complicated problem, so I don't really have a problem with that.

The solution is to build tools on top of this complexity that make it easier for developers to get their job done.

...

Nope, I disagree. The tools do help the platform, but if the base isn't simple and usable, the best tool in the world can't help you. I hate it when tools hide the complexity too much anyways. Any time there's magic happening, you're asking for trouble. This is my main problem with much of the Microsoft platform which hides much of the implementation. I don't feel like tracking every little bit that passes through my code, but relying on tools to manage complexity isn't the solution either.

Here's some thoughts on Mike's blog about the same topic:

Glenn and Duncan have posted some very interesting insights into my recent EJB rant.

In Listen to the EJBs go Pop, Duncan takes a historical perspective on how we might have gone wrong. The folks who designed the EJB technology certainly had good intentions in solving particular business problems - Use this technology for good, not evil. Unfortunately, when that golden hammer fell into the hands of the masses, every business problem started looking like a nail. It's a painful lesson that I fear we continue to relearn annually. Insert buzzword/acronym here.

Glenn approaches the "Where did we go wrong?" question from another angle in The EJB straightjacket. In attempting to solve problems, the first reaction is to narrow in on specialized tools designed to do one thing very well. Unless that one thing is exactly what you need, you're better off employing a general-purpose tool. My cordless drill is versatile and mobile enough to tackle almost any job. But when I need to bore a precise hole, I wheel out the drill press.

This is a bit from Glenn's The EJB Straightjackt post he referenced:

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.

...

Basically, it's easy to say "the tools will save us" or "this special tool will solve this special problem" but the Java community has failed to produce the magic. JBuilder is okay, Eclipse is great, NetBeans is a monstrousity. But none really help work through the fundamental problems that everyone is running into when working with EJBs.

-Russ