Ben Abernathy writes a poignant observation about computer science and the kinds of people that come (or don’t come) out of college programs.    The first group ditches computer science altogether, the second delights in making things work, but the third strives for something more elusive: elegance and beauty.  Ben is right to note that if you’re looking for beauty in software, you can very well end up a miserable idealist.

Personally, I’ve had to come to a place where I resolve to plant beautiful code wherever I can, even if it is surrounded by weeds I’m not allowed to pull.  Even when I fail at it, I find that the effort of striving to improve, rather than just make do, makes me a better and happier software engineer.

Having been in software for over a decade, I have found one easy way to spot the differences between coworkers and competitors in Group 2 (“Get it done”) and Group 3 (“Make it beautiful”): Regard, or disregard, for craft.

Doghouse Software

It’s pretty obvious when you look at carpentry, masonry, or cooking which people care about their craft, and which people just “got it done.”  Unfortunately, craft it much easier to see in the physical space than in software.  Even a gorgeous GUI can hide some unspeakably gnarly code.

I heard Grady Booch speak at Java One many years ago.  He said that most people build applications like they build doghouses:  Bang together some wood, and if the dog is mostly dry, you’re done.  Enterprise applications, he noted, are usually skyscrapers composed of a bunch of doghouses duct-taped together.

Doghouse software is built with little regard for craft.   This problem may not show up right away, but as soon as the requirements or use cases expand, the shoddy craftsmanship becomes painfully clear.   Ask anybody trying to retrofit web services on a legacy architecture, and you’ll see what I mean.

Process and Craft

Process, I must say, should not be confused with craft.  Craft should involve some process , but I’ve never seen process generate craftsmanship.  (I have seen beautiful code in CMM-4 shops and in startups.  I’ve also seen hideous crap in both.)  The difference invariably comes down to regard for craft by the individual.

Questions Asked and Unasked

“Does it work?”  If software is just a job, this is where a programmer stops asking questions.  If she cares about craft, she also asks questions like:

• “Can I prove it will work reliably? (It it testable?)”
• “Is it easy to use, does it eliminate excise?  (Is it usable, user-friendly, intuitive?)”)
• “Can I easily swap out visualizations? (Are there clear boundaries between model, view, and controller?)”
• “Will it work if it becomes modestly or even insanely popular? (Is it scalable?)”
• “Will it work if I have to add new features, or change the persistence layer, or play well in SOA?  (Is it modular, loosely-coupled, platform-agnostic, maintainable?)

These questions get at the heart of true software craftsmanship: Be in the business of building products that will stand the test of time, not one-offs with zero shelf life.

Application-wide craftsmanship can be, as Joel Spolsky rightly notes, “incredibly expensive. “  I firmly believe, however, that individuals can improve their craft and stay on budget in most situations. I have found that improving my craft improves my productivity and the maintainability of my code.

Go to the Source

Source code it often a great way to tell whether a programmer cares about craft.    Is it clean and easy to read?   Are design patterns leveraged?  Was attention paid to loose coupling, encapsulation, dependency injection?  Are there an appropriate amount of comments?   Are complex methods broken down into simpler ones?  Are there unit tests?  Does the code, and the compiled product, look like something the programmer took pride in?  Or does it “just work?”

Finding Craftsman

My quest for interviewing new hires is not just to discern talent, but a regard for craftsmanship.   It is rare that a candidate can present source code, however.  I’ve found it difficult to really learn in an interview how much a person cares about the quality of his work.

Joel of Joel on Software uses summer internships to find the kind of people he wants, but most companies can’t reproduce his model or, honestly, draw that level of internship talent.  And, lets face, it, you can’t bring in senior engineers as summer interns.

Can craftsmanship be discerned in an interview without having the source code?   If you have any suggestions, please share them in the comments below.

My mobile phone was getting a little long in the tooth, so I’ve been researching phones for a few months. As tempting as the iPhone is, I didn’t want to switch to AT&T. A couple of weeks ago I took the plunge and bought the HTC Mogul instead.

Here are the highlights that made the Mogul a perfect package:

• Slide-out full keyboard. I’m ham-fisted when it comes to tiny buttons, so having more keyboard real-estate than a Blackberry is a big win with me.
• Touch screen. You can use fingers or a stylus, the latter of which tucks into the phone shell. When you’re using IE or the Google Maps, the touch-screen functionality is indispensable. The on-screen dialing has nice big fat virtual buttons if you don’t want to use the stylus.
• Scroll-wheel. The wheel on the side is right where your index finger or thumb holds the phone, depending on which hand has the phone. If you use your mouse scroll wheel on your PC, you’ll instantly know why this is such a great little feature. It makes scrolling window panes or ripping through contact lists simply effortless.
• Wifi. If you have wifi at home, work, or lunch, you can get a pretty good connection and completely bypass your wireless plan’s data transfer restrictions.
• Windows Mobile 6. Since the Mogul has a touch screen, you get the full WM6 functionality rather than the rather disappointing “smart phone” variant.
  • With Microsoft Office mobile, Internet Explorer, and Outlook, you are carrying around a portable PC. I’m no Microsoft fanboy, but they sure come in handy.
  • Outlook Express Mobile makes it really easy to tap into my Gmail account with full IMAP support.
  • WM6 also gives you lots of flexibility when it comes to skinning the UI, ringtones, etc. Since you can turn any audio file into a ringtone, gone are the days of paying to download them from your service provider.
• Easy software development. WM6 has free emulators and .NET SDK support. This is a much nicer development platform than many phones give you.
• Oh, yeah, it’s also a phone! The sound quality is solid and it supports stereo bluetooth headsets.

The Mogul runs on the Alltel, Qwest and Sprint networks, and a friend tells me that Verizon will be offering it next month as well.

If you’re looking for a new phone and the iPhone isn’t a good fit for you, I highly recommend this one.

RSS and Atom guru James Holderness just issued a report on the how well namespaces are being handled by feed readers that understand Atom. The results are dismal:

…Matters haven’t improved much since this issue was first discussed nearly two years ago.

… Of the thirty-odd products I tested, ten ² were incapable of subscribing to a feed that used prefixed names for the Atom elements.

… More of an issue was the xhtml prefix, which caused problems for nearly two thirds of the aggregators tested.

… Of all the products I tested, there were only three that managed to pass every one of the test.

Appalling. This isn’t a reflection on Atom, however, but rather on how programmers are parsing XML itself.

In olden days (2001-2003) I worked for a company that was building a native XML database. At the time, namespace handling was probably the biggest headache around. Our product didn’t do it well, but few others did either. Considering how many parsing libraries and products there are now on the market, and how ubiquitous XML has become, I would have hoped that namespacing problems would be a thing of the past.

<bubble>burst</bubble>

All too often our applications are filled with XML seemingly drawn with crayons when the authors should have used a drafting pencil and a straight edge.

I believe one of the fundamental problems with XML is that nearly every app developer uses it, but few actually grok how to model data in it. Note that I said model data… not just dump it. Elements versus attributes, namespaces, attribute scopes, self-closing versus empty-value… these decisions can make or break a data model. If your data matters, then the form in which you represent it – and the precision derived from that form – should matter as well.

The Atom spec has model and precision down pat. Now we just need feed readers to be as careful consuming XML as the specification was in creating it.

The RSS Profile is a really helpful document that helps developers use best practices and avoid typical pitfalls when handling or producing RSS feeds.

That said, why isn’t the RSS Advisory Board – the very people who created the profile – following the profile recommendations in their own feeds?

The Feed Validator now produces warnings according to the profile, but this table shows nearly all of the individuals on the board aren’t following their own advice.

To date, these board members have valid RSS 2.0 feeds that don’t conform to the profile: Eric Lunt, Jake Savin, Jenny Levine, Brent Simmons. Matthew Bookspan and Randy Charles Morin don’t even have valid RSS 2.0 feeds at the time of this writing.

One might reasonably argue that the members shouldn’t put the profile into practice until it is ratified. That wouldn’t be a bad thing, but it is a lost opportunity to show that the profile is easy to follow. Besides, the profile was ratified a week ago. Time to eat your own dog food, guys.

Full disclosure: TechBrew’s RSS feed doesn’t meet all the recommendations of the profile either.

When listening to the radio last week, I heard somebody use the phrase “constructive pessimist.” This label captures the essence of what I think makes a great software developer. It is the kind of developer I want to be and especially have on my team.

As I thought this over, a model of sorts formed in my mind that describes four different types of engineers, each with a unique reaction to the challenges of software development. I’m calling it…

The Dutch Boy Model of Engineer Archetypes

The notion of a “constructive pessimist” implies a cartesian coordinate diagram of worker types, where each quadrant represents a unique reaction to the challenges of software development. These four engineering personality types, shown in the diagram below, typically encompass everybody on a software team.

The types can be summarized by looking at how each would handle the old fable of the dutch boy who encountered a leaky dike. Upon seeing the leak:

• The destructive pessimist knocks you down and runs away, “We’re all going to die!”
• The destructive optimist blocks your access to the dike, “Don’t worry about it, the leak will fix itself.”
• The constructive optimist sticks a piece of gum in the hole, “I fixed it!”
• The constructive pessimist sticks his finger in the hole and yells, “This won’t hold for long, go get help.”

Working with (or for) the Archetypes

These types of people are particularly obvious in software projects, but you can recognize them pretty much anywhere. Here is a more detailed description of the how each person functions in the workplace:

When faced with a serious challenge…

The destructive pessimist often defaults to, “We can’t make it work so I’m not going to bother trying.” His actions that follow usually amount to sabotage of some sort. The sabotage probably isn’t technical; it may be social, political, financial, or even just a hit on morale, but the effect is the same. This guy is poison. Fire him or get him off your project. His approach may be a character flaw or just burnout on your particular project. Either way he needs to go and take any schadenfreude with him.

The destructive optimist says, “We can make it work, but I won’t need to do any hard-core planning, designing, thinking, or testing. We’ll be positive and start coding, and we’ll do just fine.” Like the destructive pessimist, he is also an insidious influence on a team, but the effects are much more subtle. This guy is harder to get rid of, because everybody probably likes him. He may be very smart and a “good coder,” but he is an Eloi with a keyboard, unaware of the tough work required below the surface of challenging software. If you’ve heard the phrase, “Well, it worked on my machine,” it probably came from a destructive optimist. This guy will probably also refuse to document his design, comment his code, or do automated testing, because he thinks everything he does will always work just fine.

The destructive tendencies really come out if he is a manager or team lead: He’ll overrule requests for extra testing resources, he won’t manage scope creep in requirements, and he won’t recognize (or react to) the warning signs your project is headed for failure. This is also the guy who will throw extra people and overtime at the last minute on your failing project, optimistically thinking that nine women can make a baby in one month.

The constructive optimist is a fine person to have on your team, because a positive attitude and substantive work toward the goal are essential. “It will work, and I know what to do to get there.” This attitude is great, as long as they really have done the work before and know that it works from experience or solid research. The danger comes in a tendency toward “sunny day” solutions that expect everything to function normally. They don’t tend to plan for failure.

A team comprised solely of these guys will happily build a Web 2.0 website, play ping-pong, and attract angel investors left and right. The site will work great until the public notices and brings it to its knees. Not knowing the folks at Twitter, I can’t say whether this applies to their early days. I’ll venture to say that 80% of 3rd-party Facebook Apps have the hallmarks of a constructive optimist, however.

The constructive pessimist says, “It won’t work unless we make sure to do it right.” He will instinctively find weak spots, conceptual holes, and problematic requirements, then work hard to find solutions. Solid experience and the desire to find solutions in the hands of a constructive pessimist are pure gold for your project. If this guy is given either significant influence or leadership on your team – and backing by management – your chances for success cannot be higher. I should say with great emphasis that this person doesn’t have to be negative or irritable … they can be up-beat and still communicate the need to plan for rainy-day scenarios.

You expect your IT guy to be a constructive pessimist, after all. Redundant systems, fail-over support, and off-site backups are all constructive ways to plan for the worst. If your software development team thinks along the same lines, your software should be better tested, handle network irregularities, recover from errors, and be less vulnerable to malicious users.

Shaping The Team

You can’t always pick your team from scratch, so the chances of getting a a dream-team of constructive pessimists is unlikely. With a little work, I believe you can help any engineers become a little more constructive pessimist, however. You don’t have to change their personality, but you can encourage them to think and work more effectively. As the saying goes: “Hope for the best, but plan for the worst.”

I’d like to follow up this article with a second part that discusses ideas of how to do this: How do we get people in the other three quadrants to move closer to constructive pessimism?

If you have ideas or anecdotes along these lines, please leave a comment and share your experience. If you think constructive pessimism is a crock, let me know. Or if you just have some great stories of these four types of people at work, I’d love to hear about them.

Andy Brudtkuhl laments a common problem one encounters as a feed aggregator: It isn’t always simple to eliminate duplicates when comparing RSS items. This is even true when you’re comparing two items that are actually the same thing, but one has been republished.

He has discovered that when you are trying to compare the items, you can’t rely on the link alone to determine uniqueness. Essentially: the link in an RSS item is not a guaranteed unique ID (GUID).

In Andy’s case, he’s seeing items that originated from the same site, but are either linked to the original site (http://www.converstations.com/… /discovery-along.html), or have the FeedBurner link to track click-throughs: (http://feeds.feedburner.com/… /discovery-along.html).

This is one of those tough problems with RSS that the optional GUID element was supposed to solve. If the GUID element is present in the item – as is properly formed – you should be able to rely on that regardless of link variation.

Unfortunately, the RSS GUIDs are rarely used correctly among publishers, making it fairly unreliable. Mark Pilgrim discussed this back in 2004:

1. Older RSS versions don’t have it, and even in the latest version, it’s still optional. So very few feeds actually have it.
2. The RSS spec doesn’t give clear guidance on how to make a unique identifier, or how unique it really needs to be, or why you would bother. So many publishers generate useless IDs.
3. It’s difficult to compare them, because the data type of the <guid> element isn’t stable. If a certain attribute is present and contains a certain value, then the element must be treated as a string. But in other cases, the element must be treated as a URL. As we’ll see in a minute, these data types have different rules for equality, so comparing GUIDs is more difficult than it sounds.

Pilgrim and the folks working on Atom came to the conclusion that a unique id should be on every item – atom:id - and that it must be formed according to a spec that ensures canonical uniqueness. If you have an Atom feed to work with, this is a reliable mechanism.

For better or worse, however, the adoption of Atom has been slow and the market still overwhelmingly uses RSS. For aggregators like Andy (or any feed reader) who have a mixed bag of feeds, they are forced to kludge their way to uniqueness.

Update:  James Holderness reminded me of his excellent discussion on this issue from last year:  RSS Duplicate Detection.

Getting on Digg is really quite easy for the common blogger. Here’s how in one easy step:

• Get a job writing for Engadget, Gizmodo, Arstechnica, Mashable, or TechCrunch.

What, did that sound cynical? Check the latest top stories on Digg and where they came from. That’s where you need to be to easily top Digg.

If a job change isn’t in your immediate future, you are stuck with other more complicated options, such as:

1. Get noticed by one of the above sites.
2. Get noticed by an A-lister.
3. Get noticed by a top Digger.
   (or)
4. Beg all your friends for a digg and hope that 1, 2, or 3 happens a bit belatedly.

So the questions is whether or not ‘Digg Begging’ is, as one of my friends put it, “tacky or just good marketing?” Is asking your friends for diggs in the same realm as editing your own Wikipedia entry, if you have one? (Of course, if you have one, you probably don’t have to ask. )

Because the Internet is just like Middle School, the best way to solve this dilemma is to enlist your friends to digg beg on your behalf. Like the loyal Christian who woos Roxanne on your behalf, they stand between you and the sting of rejection and accusations of vain self-promotion. Parry and riposte!

Proxy beggar or no, is asking for diggs just like passing out fliers to your garage band, hoping for the big time? Or is it uploading your picture to Hot or Not, hoping for lots of MySpace friends? What do you think?

PS: Would you mind digging this story for me? I mean, my friend wants to know if you’d digg this story for him, since his account is frozen. Yeah, that’s it.

I remember the early days of Twitter, when the people you followed actually meant something to you. When your “followers” were really your friends. When it was appropriate to Tweet if anybody wanted to grab lunch. Early adopters hoped that it would become popular so that everybody could be connected like we were in the beginning.

The problem with social networks, unfortunately, is that sometimes the illusion of appearing “social” is more important than the real value of human connections. The number of people following you became a badge of honor, if not legitimacy. The MySpacing of Twitter began early in this regard.

Some kind of tide has turned lately, making things even worse. I don’t know what it is, but I’m seeing more and more people on Twitter who are only interested in using it as a marketing channel. They follow you in the hopes you follow them, and thus hear their pitches for quick bucks, diggs, or soft porn.

Thanks, Twitterweb, but no thanks. I’ll follow people I know or respect. No more automatic reciprocation. When I get a new follower on Twitter, the first thing I do is read all of their recent tweets. I’ll follow only if I see something worth following; no automatic friend-adding here.

Sadly, I see that I’m in the minority. I don’t think Twitter will recover from this shift to cheap self-advertising. It has gone from personal to pedestrian. All Biz Stone needs to do now is add the ability to play music whenever somebody views your profile, and the transformation into MySpacery will be complete.

With the announcement that the Atom 1.0 specification is essentially done, it now moves into the process of becoming a full-fledged IETF specification. Atom has been a promising alternative to RSS 2.0, but has only a fraction of the market share of syndicated feeds. Can it really compete?

Pros and Controversies

For those who are only marginally comfortable with XML, Atom is more intimidating. At the same time, it is more precise. The bungling of HTML markup (double-encoding, anyone?), confusion over enclosures, and the typical flailing we see with RSS can be addressed directly. Atom holds the promise that such problems, when they arise, can be addressed in a standards-compliant way.

The RSS 2.0 spec is supposed to be frozen, so the problems you have now in RSS will always be there… maybe. The RSS Advisory Board, divorced from inventor Dave Winer, continues to make micro-changes (against his wishes) to the RSS spec in an attempt to solve such problems. (Here’s our humorous Plumbing Fable on that soap opera.) The vitriol on this topic makes American politics look rather tame. [Editorial opinion: RSS still needs an enema.]

The Standard is the Key

The real secret to the success of Atom could very well be official stamp of approval by the IETF. This is nothing to be scoffed at: There are thousands of powerhouse U.S. corporations and defense contractors who are required by their own policy to use a official standard whenever possible in their software. As soon as Atom becomes an official IETF-blessed product, RSS as a de-facto standard won’t count anymore.

I have a coworker who is documenting my employer’s software practices for a government checklist, and one of the criteria is whether or not we are standards-compliant. If we’re using RSS instead of Atom, it would be easy to get dinged by somebody who is paying attention.

We know that the U.S. government is in fact paying attention to the RSS vs. Atom debate. Last fall, I wrote about the decision made by the U.S. Intelligence Community to go with Atom 1.0 instead of RSS. (The article also distills why RSS doesn’t work for their purposes.) They set a precedent that will make it way into policy along with the “only official standards” mandate in the defense software industry.

GoogMuscle and FeedBurner

To further muddy the waters, Google’s recent acquisition of Feedburner has the geekosphere wondering whether some GoogMuscle might get flexed to push Atom over RSS.

RSS 2.0 inventor Dave Winer is already mustering the troops to demonize (or at least discredit) FeedBurner. That camp is convinced of a vast corporate conspiracy to control RSS… and perhaps destroy it. Google has a track record of promoting Atom in the past, so it is at least possible that FeedBurner might make Atom its default format sometime in the future.

Conspiracy or not, if RSS can’t stand the test of time – frozen as it is – Atom may eventually win.  Giant corporate backers like Google who make policy decisions could very well be the deciding factor. As Richard MacManus rightly notes, “Google has the potential to be the kingmaker in the Syndication Wars very soon.” (Richard does a great recap of said Wars to date.)

Beta was Better. Long Live VHS.

All of these issues, from corporate/government standards to Google adoption is only a matter of potential, however. In the meantime, Rogers Cadenhead says Atom’s marketshare is about 16%, and appears to be declining. Standards-track or not, there is no telling if that will ever turn around. Will Atom become the Betamax to RSS’s VHS? I guess we’ll know in a couple of years.

The next big platform for app development is likely going to be mobile devices. Unlimited data plans, GPS functionality, and reasonably-good processing power make such devices a ripe target for commercial and open-source goodies.Google and Microsoft have both recently released search+map applications for the Windows Mobile platform. Microsoft has introduced Live Search Mobile and Google is offering Google Maps Mobile. (GMM is also available for Palm and Blackberry.)

I own a HTC Apache PocketPC and a Pharos iGPS locator, so I decided to take both apps out for test drive. I tested them on both my phone and the Microsoft Device Emulator for Windows Mobile. While each application offered similar functionality and a couple of unique features, there was one aspect in particular that made one of them the clear winner.

Here are the results:

Platform Overview

The phone I used is a standard PocketPC with a touchscreen, stylus, and slide-out keyboard. It runs Windows Mobile 5, a miniature version of Windows with mini versions of Office applications and Internet Explorer. It is wifi- and bluetooth capable as well. (Taking pictures of the screen in action wasn’t practical, so screenshots in this review were done with the Device Emulator.)

Download and Installation

A quick download from ls.windowsmobile.com gets you the CAB installer for Live Search (LS). The installer is 418KB, and installs with a single prompt for location. Once running, you must accept a EULA and wait several seconds for the app to load. This seems to be a first-time hit, because subsequent runs don’t take nearly as long.

Google Maps Mobile can be had at google.com/gmm, with the CAB installer downloading at 376KB. The install also takes a single prompt, with a EULA for the first run. You also must click through a text splash every time you launch GMM, which admonishes you to not use it while driving. Ahem.

Google gets kudos for a smaller URL (the less typing to get a mobile app the better) and points for a smaller download (size still matters on limited-memory devices), but the ‘Don’t Drive While Mapping’ nag every time gets old.

Map Interface and Usability

The mapping functionality of both applications are similar at first blush, but after a little use the differences become more obvious.

Both apps allow you to drag-move the maps if you have a touchscreen device. LS uses the center pad button to zoom, while GMM gives you on-screen zoom controls on the lower left. (Click the thumbnail on the right to see a side-by-side comparison of the two map views.)

Each app has a Road View to see the street layout of an area. These are functionally equivalent, but I found the Google version to be easier in bright sunlight, because the colors have more contrast.

If you’re in an area where traffic data is available, you can get traffic overlays for both applications. This colors major roadways with red, yellow, or green according to traffic speeds. Updates are pulled by both applications on a regular basis, about 2 minutes.

From here, the usability of the applications begins to diverge.

Microsoft’s Arial View provides a photograph view with overlaid street names. I have always found this perspective to be a compelling one, but the street names are essential to keep your bearings. Google’s Satellite View is photographic as well, but the street names are glaringly absent, making the view useless for most uses. Normal Google Maps have a hybrid view, so the omission in GMM is as puzzling as it is annoying.

When you have used search functionality to put a marker on the map, I like the way that Live Search displays business telephone numbers right there. GMM makes you click the marker to see the phone number. One other nice thing that only LS offers is the ability to name a given location (like ‘work’ or ‘home’) for easy reference later. Granted, you shouldn’t use these applications while driving, but if you’re trying to find something while at a red light, the fewer clicks the better.

Both applications are both GPS aware, allowing you to center a map at your current location. GMM puts a small blue ball on the map to represent your location, whereas LS has a directional triangle to show location and orientation. The triangle is easier to see, and the orientation aspect is really nice. Unfortunately, I experienced a number of hiccups with LS when it came to location updates, so it was ultimately much less reliable than the GMM functionality.

On the flip side, LS takes little advantage of the touchscreen capabilities of the PocketPC. While GMM lets you click-and-hold anywhere to bring up a context menu for handy commands, Live Search makes you go through the bottom menu bar for nearly everything. This essentially forces you to use the stylus or use the directional pad as a stand-in for arrow keys.

One last factor in the area of usability: GMM offers a number of keyboard shortcuts (see the help file for details) to perform common tasks. LS offers neither a help file nor any shortcuts that I could find.

Search Capabilities

Both Live Search and Google Mobile Maps let you search (screenshot) for things near your location. This lets you quickly find the closest hotel, restaurant, museum, or whatever interests you.

Live Search lets you search by either drilling down through business categories or using free text, whereas GMM only offers a free text search. I didn’t think I’d care much about LS’s category feature, but I found it really nice when looking for restaurant ideas.

Once you’ve found something, both Google Maps Mobile and Live Search give you options to save it to your contacts (address book), see it on a map, get directions to it, send the info to someone via SMS, or just call the phone number outright. LS lets you tap a phone number to call it, while GMM makes you use the options menu.

Routing (Getting Directions)

You can use either app to ask for directions to a location, but the way this is handled is perhaps the biggest divergence between the two.

Live Search gives you a series of text directions, each of which can be clicked to see it on the map. The route is overlaid on your map, with each waypoint marked as a tiny circle. The circles are click-able, but you’ll need a stylus and a steady hand to actually hit them.

Google Maps Mobile shows the directions on the map with a callout for each step. You are given forward and back buttons on-screen that take you through the waypoints. Each waypoint is a large diamond, making them really easy to spot or select.

Here are screenshots (1, 2) of the two apps side by side.

After using both of the approaches, I found myself wishing that each app had some of the functionality of the other. I like the list of directions when I’m in a familiar area. (“Turn left on Academy for 2 miles, Turn right on Platte for 1 mile”) But the turn-by-turn laid on the map is also really handy when you don’t have a good mental picture of the intersections. This distinction alone is enough to make me choose one app over the other, based on the use case for needing directions.

GMM routing has a killer feature that bears mention. As stated earlier, it is much better at utilization of the touchscreen than LS. Accordingly, you can tap anywhere on a map in GMM and mark a starting point and end point It will then calculate and display the best route. This is simply perfect when you don’t have the time to key in an exact address.

Performance Considerations

A video is worth a thousand pictures, so I did a quick video demo of each app going through the paces. The goal of the demo was to start at Invesco Field in Denver (formerly Mile High Statdium) and find a nearby famously-named night club. (Disclaimer: I’ve never been to either.) The videos were originally intended to show you how each works, but they also illustrated just how much slower Live Search was when performing the same tasks.

Click here to view the embedded video.

Click here to view the embedded video.

If you’ll grant a fudge factor for missed clicks or hesitations on my part, you’ll see that GMM is still considerably faster than LS to accomplish the same basic task flow. The entire sequence took about 2 minutes with Google Mobile Maps, but it took 3 minutes to finish with Live Search. Since the average red light cycle is 2 minutes in U.S. cities, that extra minute feels like a lifetime. Because we wouldn’t use these while driving. Ahem.

The Votes are In

Okay, technically only one vote is in: mine. Here’s a recap of the comparison:

• Both apps had an easy install, although Google’s was slightly smaller.
• Highlights of Live Search are the arial view, categorical searching, GPS orientation on maps, and name-able locations.
• Google Maps Mobile strengths are touchscreen integration, on-map routing, and more reliable GPS integration.
• Live Search performance is noticably slower, in everything from zoom animation to map dragging.

The verdict: If you don’t absolutely need the satellite view or categorical searching, Google Maps Mobile is the clear winner by a long shot. A better GUI and faster application performance prove to be indispensible when you’re in a hurry (or have a limited data plan.)

My hope is that the next version of each app takes careful notes from their competition. GMM needs street overlays on the satellite map, GPS orientation, and a list view of routing directions. LS needs more on-screen controls, better on-map routing, and it needs to hurry the heck up.

If you have any observations or rants about these two apps, drop a comment below. I’d love to hear about your experience.

RockStarApps has put together a handy “Ajax Maps Bake-Off” which lets you see how the biggest Ajax-driven maps compare side-by-side. The page loads a Microsoft, Google, and Yahoo map side-by-side, and keeps them synchronized for easy comparison.

The performance is – understandably – a little slow to keep the three maps sync’d, but it is nice to have an apples-to-apples view of how each system handles the little details.

• I find the rendering of Microsoft’s Live Maps to be superior to either Google or Yahoo. The MS maps are more like one you’d have in your car’s glove box, with nice terrain details like the locations of streams and creeks.
• Yahoo Maps has better color contrast than Microsoft or Google, which is important if you’re using a mobile device with a small screen.
• Microsoft and Yahoo display directional information on one-way streets, a must-have that Google has omitted. (I would much rather know whether the street I’m approaching is one-way than see somebody’s cat in a nearby window.)

The plumbers union may be reuniting.  Dave Winer, inventor of RSS 2.0, has offered to re-join the RSS Advisory Board, albeit with a firm caveat:  The board will make no changes to the specification, just clarifications via a profile.

I will join as a member, if you want me to, to help give it legitimacy. At that point these time-wasting discussions can end. I would also suggest that you offer Sam Ruby a position, esp if he takes the first item here to heart.

The two things:

1. Recognize that the RSS 2.0 spec is on the Harvard server, and it is not going to change.

2. Change the mission of this group to working on a profile. Let’s come up with a memorable name for the profile that doesn’t sound official or mandatory, and let’s get to work on solving problems, and then promoting the result to the users.

All things considered, I think this is a great offer. It is one that might finally produce the clarifications to the spec that people have been seeking for years.  If Dave is finally willing to answer those clarifications, even in a “non-official profile”, it would be good for everybody.

Once upon a time, you had to go to a plumbing store to buy the stuff for a new sink. You’re going to need clamps, hoses, faucets… the works. An employee at the store with “Dave” on his shirt comes up and says, “I recommend the Really Simple Sink. I invented it, and it just works.”

Another guy named R.C. wanders over and agrees. “I love it. The faucets works pretty well, but there are a couple of extra parts you need to make sure it doesn’t leak. People make a lot of mistakes when they install it. So some of us have made a couple of minor changes to the seals and valve stems.”

Dave looks miffed, “The sink is fine the way it is.” He juts out his thumb at R.C., “Pay no attention to him. He only installs sinks, he’s not authorized to modify the design.” R.C. looks surprised, “You said I could, and you were even helping me.” Dave shakes his head, “I stopped helping, and never said you you guys could change anything.”

“Yes, you did.”

“No, I didn’t. The design is fine.”

“You discontinued this line, so customers can’t ever upgrade. To use the sink, people have to change some parts and get a better instruction manual.”

“No, they don’t!”

“Yes, they do!”

At this point the debate starts getting pretty heated. You get the sense they’ve had this discussion before. While they argue, you notice another employee in the next aisle. You go talk to him, noting the name on his shirt. “Hi Sam, I need a sink.”

He nods, “Try this one by Atom Manufacturing. It isn’t as popular as the older Really Simple Sink, and it is a little harder to install sometimes, but it serves the same purpose.”

“Will it leak?” you ask. Sam nods again, “Not usually, but anything can happen over the years. But if it does, you can upgrade it to a newer model. The design is actually an industry standard, so a bunch of plumbers are constantly working together on how to improve it.”

“So… what happens if the Really Simple Sink leaks?” He shrugs, “You’re out of luck; the sole inventor has discontinued that model. He’s focusing more on open-pipe machined levers these days. So, you’ll have to figure out how to plug the holes yourself. But that may not be so bad in a residential setting.”

“Oh,” you say, “But I have to install this one at work.” Sam raises an eyebrow. “You’ll want to be careful, then. Commercial plumbing has higher inspection standards.”

“I guess I’d better buy the Atom one, then.”

He smiles, “Oh, they’re both free. It’s the cost of owning one you have to watch out for.”

The End?

“Calling The Plumber” by Red Rover Studios

Click here to view the embedded video.