Eclipse This!

We've got a saying at work: Open-source is a ghetto.

As much as I love open-source software, as much as I love the idea of open-source software, so much of it is just, well, crap. One of our most frustrating day-to-day ordeals is to work with Eclipse, a Java IDE (and then some) that is often considered to be a pinnacle of what open-source software can be.

Now take a look at the following screenshot (package names redacted for corporate anonymity):

Click to expand

Notice the Problems tab at the bottom. This lists the current problems with my code; until all the little red x's go away, things are bad and I really can't move forward. There is exactly one problem in the above example, with the oh-so-helpful description: "Syntax error on tokens, delete these tokens."

Normally, I'd be frustrated by such an ambiguous error message, but that's...ahem...eclipsed...ahem...by a bigger issue. You see, our helpful Problems tab indicates that the problem occurs on line twelve of the currently opened source file. Go ahead and find line twelve. I'll wait.

...8, 9, 10, 11...14!

That's right, lines twelve and thirteen of this file somehow don't exist. But until I delete some mysterious "token" on line twelve, my project is fubar'd.

Grrr.

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.

Search and the Art of Celebrity Gossip

Internet search is a huge business and those fighting for the market are giants. Google dominates, with Microsoft, Yahoo and other legacy players fighting for its leftovers. Rather than delve into the business analyst's world to justify Google's share, let's just take a look at their websites from a user interface perspective.

First, there's MSN.com:

I was going to search for something serious, but I think I'll read about that serial shrimp shoplifter instead

Let's see, the eye is first drawn to the main headlines scrolling by. In this screenshot, that's the "Is It Them...Or You? Why you haven't met The One." Then there's "Hot or not? 100 women vote on spring's freshest trends." There's also some giant ads, like that one for Bank of America. And, of course, below that there's MSN autos with a Hyundai ad placed in such a way that it isn't immediately recognizable as an ad. Their "Today's Picks" include news of a "serial shrimp shoplifter." And let's not miss that little gem at the bottom, "Best pet for you by zodiac sign!"

Oh yeah, there's also a search bar up at the top.

On to Yahoo.com:

Yes, I use Google Chrome. It doesn't make me (too) biased.

It's a pretty similar layout. The biggest element on the page is the ETrade ad on the right. It's also animated, which makes it rather obnoxious. The featured headline news starts with the "Most extreme golf hole," and also includes, "Worst dating mistakes that women make." Below that, mixed in with some serious world news is the video titled, "Surgeons save man who accidentally swallowed scissors," which feels just one step up from the myriad YouTube videos of people getting hit in the nuts. To top it all off, look near the bottom right for "Popular Celebrity Photos."

And finally: Google.com:

Surprise! This screenshot is smaller.

Yep, there's the search bar.

Also notice that there are no news, no dating tips and, most stunningly for the leader in web-based advertising, absolutely no ads.

That's is a huge difference from MSN and Yahoo. Google is a serious site meant for serious people. I can pull it up at work twenty times a day - which I do - and I feel like I'm using a professional tool.

MSN and Yahoo, on the other hand, have some serious issues with inane clutter. Not only do all those extra headlines draw focus away from what I really want do, but take a look at the content itself. Celebrity photos? Horoscope-friendly pets? These aren't professional tools, they're supermarket tabloids!

How to Get a Job, Part IV: No No's

A week into holding interviews, here are a few things I've had happen that pretty much disqualify you for the job:

1. Fail to read the job posting. The posting said that you need to be a US citizen right up there at the top. You're not a US citizen? I don't feel sorry that you just drove an hour to get here.

2. Fail to understand what an interview is. Don't send me an email half an hour before the interview asking me if it is a real interview or a phone interview, and then asking to reschedule since I actually want to meet you. I'll still meet this guy, but he just dropped down to the bottom of the pile.

3. Be nervous. I know understand this little bit of performance anxiety, but get over it. I like confident applicants that act like they've done this before; they tend to do better under pressure when they get the job. If you're afraid of me, just wait until the owner of the company tells you that he needs a miracle five minutes ago.

4. Dress unprofessionally. Seriously: go put on that suit. You've lost me when you show up in jeans.

5. Ask me how to make a resume. I came across someone and mentioned that I was hiring. Just so happens he was looking, so I gave him my email address and told him to send me his resume. His response? "I've never made a resume, what should I put on it?" Sorry - a professional knows how to do this, and I'm not going to babysit.

6. Send me a resume that I can't read. That's right, I actually got a resume with no file extension or other type information. And you want a position at a software company?

7. Show up blind. We put a lot of effort into our website. Take five minutes to find out a little bit about our company.

How to Get a Job, Part III: The Setup

I freely admit that I'm a bastard.

Once I comb through the pile of resumes, I choose a few candidates that look the best / least worst and send out emails inviting the potential employees in for an interview.

I see every part of the interview process as a chance to glean just a little more information about candidates. When it comes down to it, most candidates have the same answers to formal questions, so I like to use bits that don't seem like formal questions. In this case, I give them the company name, but not an address.

A smart candidate will Google the company, find our address and write me back, "Is this the correct address?" A less promising candidate: "Send me your address." I like candidates that can find their own answers; I hate babysitting.

So much of IT is being able to answer questions for oneself.