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.

Think, "Keanu Reeves"

List whoa = new ArrayList() {{
    add("foo");
    add("bar");
}};

Yes, this is real Java. It even does what you'd expect: it creates a new list and adds two items to it.

I've been programming Java for years, I've even taken the test to become a Sun Certified Java Programmer, and yet I've never seen anything like this.

To sum up: whoa.

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!

Technology Predictions, 2009

I've been copied on several correspondences about predictions for the technology sector in 2009. Kurt has already covered the general rubbish-ness of at least one particular article here. Rather than cover the same terrain, here are Evan's Tech Predictions '09:

1. No Major Changes. That's right, nothing really, really big is going to happen in 2009. This is a year for small, incremental evolution of technologies already in the pipeline.

2. Dynamic Languages will Continue to Wane. I remember 2007 and 2008 when the only things on anyone's lips were Ruby, Rails and Ruby on Rails. Those were magic times, when so many of us in the industry went through the tutorials for how to make a full-featured blog website in 15 minutes using Rails. We oohed, we ahhed. What power! But something has happened in the last few years:

We've had time to work with these languages.

In a vacuum, dynamic languages are extremely powerful. In the real world, they are rather lacking. Static languages and static typing are powerful tools when developing larger systems with larger teams over larger periods of time.

They also wipe the floor, performance-wise.

I'm not going to defend every static language out there - there are plenty of reasons to criticize them, even my favorite Java. But these larger, static languages have been developed over a long time and, more importantly, with an eye towards a much larger community. They aren't designed to do one thing wonderfully, they're designed to do everything just fine. While some argue that development teams should use several languages, each for the right job, I know just how badly that can come back to bite you when developers leave and all of your expertise for part of your product line walks out the door. I, for one, have no interest in creating a Programmer's Tower of Babel.

3. SaaS and SOA Will Continue to Be Meaningless Buzzwords. Words are useful because they have meaning. SOA (Service-Oriented Architecture) and it's offspring SaaS (Software as a Service) - along with perennials like "Web 2.0" - mean different things for everyone that uses them. And don't get fooled: those pushing these terms are salesmen doing nothing more than trying to part you from your money.

Take SOA, for example. For some, it meant web services - specifically, SOAP over HTTP. Others used it describe an architecture of coarse-grained components glued together to form a composite. Still others said it was a fine-grained version of the same. Some focused more on decoupling (with an Enterprise SOA Center of Excellence to develop shared XML schemas!), while others emphasized a particular software stack. To just about every business that bought into the idea, SOA meant throwing millions of dollars down a hole to nowhere.

This isn't coincidental: buzzwords kill. They hide details in ambiguity while trumpeting benefits. They're the salesman's weapon of choice, and by now developers should know better.

4. Experiments in Simplicity Will Thrive. Slowly. Just like the the housing market, the bubble has burst on big vendor SOA/XML/WS-MAGiC/Etc. Much of what we see now is the continued search for smaller, simpler and faster. Spring has capitalized on it big time and others are racing to follow suit.

XML is being supplanted by JSON and Google Protocol Buffers. Users of complex JMS and similar protocols are reverting to HTTP. Heavyweight SOAP is increasingly replaced with lightweight REST.

All of these alternative technologies have strong followings, but users will continue to be more cautious in adoption. More importantly, in good post-bubble fashion, we won't find everybody going in the same direction.

5. Open Source Wins Hearts. Take a look at Sun Microsystems. Sun has been vigorously flying the flag of open source, first releasing Java under GPL, then following suit with just about every other product. Then it bought MySQL. Even President Obama has asked Scott McNealy, Sun chairman, to write a white paper about how open source can benefit government.

But this isn't about Sun. Remember when business people looked on at open source with skepticism? Now: remember how long it's been since you've seen that attitude?

The new open source is different, though. This is less about the New Service-Based Business Model and more about cooperation and collaberation. Developers have taken to open source because it helps them, as a community, develop better software with less effort. Their resilience has finally leaked through to the mainstream.

6. The Winners Will Deliver Value. And nothing more. Solve a real problem and people will give you money, provided you don't ask for too much. The good news? There are still lots of problems out there.

Plenty of firms, from law practices to health care providers, are still struggling to figure out how to leverage information systems for real business purpose, especially in document management and archival. Big IT shops need better tools to manage ever-increasing inventory. Governments - local, state and federal - need better ways to connect employees, communicate with the public and increase efficiency (and might I suggest that they find ways to shorten lines at the DMV). The winners won't just think of cool things that technology can do, but will identify a problem and develop a solution. Then sell it.