The most basic failure

In this holiday buying season the Kindle and the Nook continue to be very popular, and the battle still ranges over the viability of dedicated e-readers versus general purpose devices like the IPad.

Poor Sony.

I own one of the Sony E-Readers and quite like it. It has many advantages over the Kindle, Nook or IPad and yet its largely forgotten. I have a theory as to why.

Sony forgot to give its product a name! Quick test: what is the name of Sony's e-reader? Its "E-Reader". Since thats also the generic term for the device it amounts to not having a name.

Sometimes having the generic name for the device is a good thing. Xerox has the generic name for the photocopier. The important thing however is the timing.

Its a Good Thing to have your product name become the generic name. Its a Bad Thing however to simply use an existing generic name.

Imagine a device making introducing an MP3 player and calling it "MP3-Player". Rather than subsuming all the good will associated with the general product this new device would feel like a cut-rate generic device.

I think thats what happened to Sony's device. You can't even talk about their reader. I can't tell you how many times people have asked me: "is that a Kindle?". I say "no, its Sony's Kindle", which is certainly not an answer to warm the hearts of Sony's marketing department.

I don't know what surprises me more, the fact that Sony forgot to name their device, or that no one seems to have noticed this failure.

Guest Blog over at RubyLearning.com

I am the guest blogger over at RubyLearning.com this week. My article on the value of maintaining a personal bug log is at: http://rubylearning.com/blog/2010/10/25/the-value-of-a-personal-bug-log/.

Although I'm not a Ruby programmer the RubyLearning blog run occasional articles on learning in general.

Profiled for JavaOne

I was recently profiled for the upcoming Oracle JavaOne. This was because of my open source project Log4JFugue.

The link is: http://www.oracle.com/us/javaonedevelop/future-of-java-168616.html#tarbox

It was interesting to sit back and think about what makes using Java interesting. It also reminded me of the freedom that comes from having an open source project. If I want to explore using Groovy I don't need to get the approval of a committee I can just do it.

Where do you get your Intellectual Stimulation?

Most of us work in jobs that primarily focused on solving an immediate need for existing customer, who needs a quick solution today. This certainly pays the bills but generally isn't the kind of venue to leads to discussions about to create "software that sings". Indeed when I used that phrase in a previous article I got comments that even thinking about writing such software was beyond the pale for most people.

So, where do people find an outlet for that part of the mind that goes beyond solving the problem for today? Having just come back from the Atlassian Summit 2010 I can tell you how recharging it was to spend a few (long) days surrounded by people whose mission it was to be better. One of Atlassian's commitments this year is for their tools to save every developer 15 minutes a day. It was fun to spend time thinking, arguing, brainstorming about how to change tools and processes to squeeze out an incremental amount of productivity. And then I went back to work. where the focus is (as it should be) on the short term deliverable. I suspect I'm not alone in this regard and wonder how people recharge their batteries.

Some years back I visited The Orchard tea room in Cambridge, England. This humble tea room hosted Virginia Wolf, Bertrand Russell, Ludwig Wittgenstein and others. Its as if Edward Tufte, Richard Feynman and Claude Shannon hung out together at the local Starbucks. Imagine sitting at the next table from that gathering every week! Without putting myself in such company I wondered if such places existed today where motivated people could gather and discuss their craft.

Our conferences and User Group meetings try fill this role but to a very limited degree. Its tough to have an in depth discussion at a 15,000 person, $5000 JavaOne for example. User Space conferences may be better for this but they're still discrete events rather than something ongoing. I started wondering about other models such as the JavaPosse. That's a group of four friends who meet once a week or so and basically spend an hour discussing whatever they find interesting. While the Apple bashing/praising they engage in has gotten a bit tiring it’s still a very interesting model. The parts that stand out for me are:

- its a regular meeting rather than an occasional event
- it happens (mostly) in person. The four members actually sit together and talk
- it's outside the work venue and not paid for by my employer so I'm not obligated to focus on near term problems/solutions

I've decided to start a similar group myself, not with the intention of podcasting it but simply to spend some regular time talking with smart people about the craft. We currently have three members and are carefully thinking about a couple more people. We're also trying to determine what kind of meeting place we should have.

I wonder if anyone else has tried something like this or if anyone has other ideas for on-going mental stimulation?

Follow The Sun versus Chase The Sun

Follow The Sun is the management concept that by spreading your development team across the world you always have someone who is awake and can work on a problem. In the imagined perfect world Team A works on a problem for their eight hour day and then hands off the partially developed feature to the next team arriving on the next continent. The idea is based on the notion that developers and software are both fungible assets. (Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution. Examples of highly fungible commodities are crude oil, wheat, orange juice, precious metals, and currencies. Wikipedia)

Since developer A is equivalent to developer B it just make sense for them to hand off bits of partially developed code to one another. (sic)

In the real world this often becomes Chase The Sun rather than Follow The Sun. There are two variations of Chase the Sun.

In the first variation all developers are basically expected to be available for questions and support 24 hours a day. Between Skype and text messages and laptops or smart phones we often see developers basically in perpetual on-call mode. This can actually be effective...until the team burns out.

In the other variation team A makes a change that breaks the system or changes it significantly, and then goes to bed. Team B comes to work to find a broken or "different' system and spends their day doing archeology on team A's changes. Successful or not they try to warn Team C about the state of the system and the changes that they've made in an attempt to resolve the issue.

Each team leaves emails that will be read 18 hours later by the team prior to them in the earth's rotation. Besides being inefficient this variation leads to predictably negative team interactions. Its just too easy to explain each day's problems as being caused by "them".

Chase the Sun can be changed back into Follow The Sun by following a few simple rules

a) developers are not fungible

b) there is enough code that the code also isn't fungible, so not everyone will understand everything

c) geographically dispersed teams can assist each other investigations or in remote pair programming where one team develops and the other tests

d) asking geographically dispersed teams to work on the same code or features is often a recipe for disaster

April issue of PragPub is out, see my article

The April issue of PragPub, the magazine by the Pragmatic Programmers is out, and I have another article in it. The link to my article is http://www.pragprog.com/magazines/2010-04/medicine-making-music and the link to the whole issue is http://www.pragprog.com/magazines/2010-04/content

My article is about an NPR report I heard where some ER's are using music is a way that seems similar to my open source project Log4JFugue.

Check it out!

A trick for managing workspaces within Eclipse

There are lots of ways to deal with the issue of multiple workspaces within Eclipse. The way I approach it is to have all of my workspaces live under /opt/workspaces and have them all available at the same time. This allows me to switch back and forth between projects easily. It does have a drawback however, but I've found a way around it and thats the topic of this post.

If you multiple workspaces open and you use the Cntrl-Shift-T class finder to navigate between classes you will be shown a list of with search results from all of the workspaces. Chances are you are only actually working in a single workspace at a time. Wouldn't it be great to only see results from the workspace you are actively working in?

There is a drop down arrow in the upper right corner of the Cntrl-Shift-T dialog. That brings up a "Select Working Set" dialog. Press "new" and then "Resource" to select just the project you are working on. From that point on your class searches will be limited to that project.

The one other step to do is in the Project Explorer select the project you are working on and from the right-click popup menu select "go into".

These two tricks let you have the best of both worlds, context that is limited to your current project along with trivial switching between projects.