Dan Steinberg had a provocatively titled post on java.net today. He took exception some comments on Kathy Sierra's java.net post about the interaction of developers with customers.

It seems to me that its part of the culture of companies to keep their developers as far away from customers as possible. I think that this is a mistake. Before XML4J went open source, the code was hosted at IBM's alphaWorks site. You could get a binary download, as well as the source code. The development team was front line tech support. We answered questions in the forums and via e-mail. It was a precursor to what we'd experience when we went open source. And we got some very valuable feedback from our users/customers about things that were working and things that weren't. We learned what people were trying to do and developed features to facilitate that. It was really important.

Also during this time, I was asked by my upper management to go to a customer site with someone from IBM's services group. That's right, IBM actually sent a development engineer to a customer site to learn about what they were doing and how they were trying to deploy our technology. I don't know how pervasive this practice was in the rest of the company, but it was a great experience for me. I got unfiltered data on what people were trying to do.

Dan took exception to the part of the comments about Marketing and PRD's. There's a nice theory that says that Marketing knows the customer and what they want and that they pass that information directy to the developers with no loss of information. Unfortunately, that doesn't seem to happen very often. More often than not, the feedback loop is open, and that's disastrous

This is one of the potential benefits of open source development -- you have the possiblity of a close customer/developer relationship, which can be a very postitive thing. Of course, this doesn't require open source -- I just exchanged a series of e-mails with Brent Simmons the developer of NetNewsWire and I was very pleased that he was receptive to my feedback.

Build it, get feedback, repeat.

Today I was playing with the Eclipse on Mac OS X, and I wanted to move the workspace directory out of the Eclipse install directory. On the Windows version of Eclipse (and I assume the Linux version), you can specify the -data flag to the Eclipse launcher to do the job. Unfortunately, this doesn't work on the Mac. I posted a query to eclipse.tools.jdt and got instructions on what to do.

You'll have to edit the Info.plist file:

- do a Control-click (or right button mouse click) on the Eclipse application
- from the context menu select "Show Package Contents"
- in the new folder double click on "Contents"
- open the file "Info.plist" with your favorite text editor
- at the end of your file (after the "Eclipse" key) change the existing
  arguments or add a new argument (enclosed in a <string> </string> pair).

Be aware that there is already a "-data" argument.

If you want to have your workspace in your home directory, you can use a '~'
character as a shortcut for your home directory.

So with the following two arguments your workspace will be created in your
Document folder:
    <string>-data</string><string>~/Documents/workspace</string>

I've been hoping that the Eclipse folks would steal a feature from IBM's Websphere Studio Application Developer, which allows you to select a workspace directory from a dialog at startup. This plist editing on the Mac is a really good reason for doing the dialog. What if I wanted to switch among a few workspace directories?

Today I finished Kent Beck's Test Driven Development: By Example. I started reading this before I started on the unit tests that I've been working on for the Chandler repository. Now I wish I had finished it earlier -- might have saved myself a little work.

The book is divided in to three parst. Parts one and two are a pair of examples developed in a test first style. There is a lot of minute detail and coverage of the reasoning. Some people might find this boring, I found it enlightening to see the inner thought process at work at various points along the way. The third part goes on to cover general principles of TDD. This section contained some good practices that I hope to put in place when I start back to work next week. If you are interested in the buzz/hype around TDD, I think that this book is worth a look. Suggestions for other worthwhile TDD books are welcome.

Today I paid my first visit to #joiito. At ApacheCon, Mark Pilgrim and Joe Gregorio told me that #joiito was the place to be. It's been on my list for a while, but I just didn't have time. So anyway, I stopped in, to see what the fuss was all about. I ran into Mark and Joe, so that was good. jeanniecool showed me the joibot ropes, and Maniac greeted me. Not bad for a first day in a channel of mostly strangers.

The whole IRC bot thing is new to me -- I know bots have been around forever, but I haven't done much IRC until this year, and I'm still climbing the learning curve. I wish that I could find a passable IRC client for OS X. I discovered akwairc and ircle today, so maybe I'll get around to trying them in the next few days.

Julie just popped in to tell me that my sales rank on Amazon is 89,461. That's a significant improvement from 700,000+. Of course, the distribution of sales on Amazon is likely to be a power law shaped curve, so the sledding only gets tougher up hill.

It's an odd experience shipping physical products. I finished writing the book in September and there've been little things to do here and there, but it's been mostly out of my mind since then because I've go so many other things going on. I've gotten so used to finishing something and having it go into use that it just feels weird to have this delay before the books go out. Even now it doesn't quite seem real yet, because I haven't seen a copy of the physical book yet. I hope that my copies are on the way.

I had a similar feeling when I as working on the Newton at Apple. Talk about lag time. We had to finish our software much earlier than I was used to, because that software was going into ROM, and there was lead time for that, coupled with the vacation schedule of our production partner in Asia. Working on something physical, like a piece of electronics, or a book is definitely a different feel from just tagging a bunch of files in CVS, jarring them up and pronouncing it done. Of course, not all software is done that way, but more and more software is getting done that way.