Eclipse Galileo Re-Reflection

A few gentlemen stopped by and posted a few comments in regards to my first Galileo posting. I'm really not sure how they made it out here to my little island, but I'd like to say welcome.

I'd also like to clarify a few things.

First off, I hope that the Eclipse Rich Ajax Platform (RAP) guys don't feel like I'm picking on them. My RAP examples are just that: examples. To those of you who stopped by and replied: thanks for taking criticism in stride; it is a mark of a true professional. Kudos.

I hoped that by contrasting the documentation of RAP and the Google Web Toolkit (GWT), I could highlight exactly one thing. Good documentation is the single best investment that a development team can make in usability. In fact, when I propose that my team choose between competing technologies, the choice has oftentimes come down to discoverability rather than technical merits.

If we choose a sparsely-documented technology, senior developers first take a crack at it, taking a week or three to dissect the technology and learn everything they can about it. They then take it to junior developers, teaching them hands-on. After that, implementation still takes a great deal of handholding by our senior people - people that, all things considered, have much better things to do with their time. Eventually, the team splits up into gurus and neophytes and only certain developers are willing to touch certain parts of the code base. Ultimately, the result is rarely clean and often buggy, requiring an extra iteration to clean up before going live.

A well-documented technology, in contrast, puts developers on a much more even level. Junior and senior developers can learn simultaneously. Code develops an extra sense of mobility as everyone feels confident with the entire code base, and the end result is a more cohesive, more robust product.

In short: good documentation allows developers to focus on solving an actual business problem.

Unfortunately, most open source projects I've used have been badly, badly documented. I understand that documentation is difficult and extremely un-sexy. I still can't stress enough that for me, as a user, the next major step forward for open-source - to promote usability, gain legitimacy and increase productivity - is to focus on documentation.

And for the record: I am more than happy to help contribute. Unfortunately, there's a bit of a catch-22: I can't document what I don't know, and I won't know until there is documentation. That said: if anyone ever feels that there is something that I can do to help, this is an open invitation to get in touch with me.

As for the systemic problem of community-wide documentation, I do have some ideas. I've already started writing that post and will publish as soon as I can.

Eclipse Galileo Reflection

There is no shortage of bloggers extoling the virtues of Galileo. While the new release builds on the strengths of Ganymede and adds some welcome functionality, it doesn't address the core deficiencies. Namely: documenation, documentation and documentation. (Also: documentation.)

I like Eclipse. My team and I have been building applications with it for over a year, most notably using the Eclipse Rich Client Platform (RCP). I hope that I can make this criticism and also express that I mean no disrespect to those that have put so much time and effort into the release.

That said, without better documentation, most Eclipse projects are not usable.

We've just finished the first iteration of a project using the Google Web Toolkit (GWT) to build a rich web application. After reading blogs and looking through new features of the Galileo release, the Eclipse Rich Ajax Platform (RAP) caught my eye and I decided to investigate it as a possible alternative.

I got nowhere.

There are several interesting demos and screen captures, but none that can even get me started down the road to building a practical product. The getting started page barely gets past installation and while the Wiki does a decent job of explaining the overall architecture, I'm still at a loss for practical information.

Compare this to the documentation for GWT. There is a clean walkthrough for new users. They do a great job of explaining not only what the API does, but why they made certain design decisions. Moreover, they provide more than just an introduction; they provide tutorials that walk users through advanced topics including debugging and deployment.

I can't even find JavaDocs from the RAP site.

Eclipse is a powerful tool. It is necessarily complex - and I've often defended its complexity. But without good roadmaps, the learning curve becomes prohibitive. It took no less than three books and hours upon hours of searching wikis, forums, newsgroups and blogs to get through our first RCP application. It is a scenario that replays itself every time we try to use an Eclipse technology, be it RAP for web applications, Buckminster for builds or GEF for diagramming. Most of the time, we abandon the effort.

We just don't have the time or energy to keep going through that.

If Eclipse wants to be taken seriously - and it deserves to be taken seriously - it needs to focus not on building powerful features, but empowering developers to leverage the platform.

Not Yet, Young Grasshopper

If you haven't yet heard about Bing, Microsoft's new search engine, you soon will. The software giant plans to spend around $100 million dollars to make sure you do.

So...is it any good?

As I've said before, I view the search engine as a professional tool, not a plaything. I search dozens of times each day to help dissect the convoluted world of software engineering.

I needed to find out about integrating two software libraries I'm using, Google's GWT and Guice. I'll be honest: I went to Google first and got exactly the results I needed. As an added experiment, I went to Bing and tried the same query.

The result? When I typed in, "gwt guice," Bing decided that I really meant to search for "get guide." Not sure how that one works. I'm really not a fan of software that thinks it knows what I want better than myself.

Needless to say, I'm sticking with Google.