I haven't posted much about my enjoyment of motorcycles, but yesterday I took the next step in my ongoing series of motorcycle experiences.

My new bike is a 2005 Suzuki DL1000 otherwise known at the V-strom. I'm looking forward to getting to know it a lot better. The previous owner put a lot of aftermarket farkles on it including heated grips (incredibility useful as it was 40F on the way home) and a custom seat which seems great so far.

For the last few years I've been riding this 1998 Ducati ST2, which has been a wonderful bike, but as I get older the position gets more uncomfortable the longer I go. And lets just say it is a tad expensive to maintain.

Back in the day I rode one of these to and from work. Things have sure changed.

Are you or someone you know an expert in Sybase MobiLink? I am looking for someone to help us out by doing some knowledge transfer, performing a readiness assessment and assisting us in the deployment of MobiLink that underlies a new solution we are offering.

This will be a contract engagement that I expect this will start as a week of on-site time followed by additional occasional consulting.

Contact me if you are interested or have questions.

Via Jeremy D. Miller

This post by David is hilarious (warning programmer humor...)

I've heard Christopher Avery speak once and had a couple of email conversations and I have deep respect for the message he is trying to get across.

His e-Tip from Feb '06 is this:

Three ways you and I reduce our ability to respond and lead everyday:

• Denial. We close our eyes, cover our ears, and hum a comforting tune.
• LayBlame. We take the position that our problem is really 'them'.
• Justify. We say that it is 'just' the way it is.

Which of these 3 things have you seen in your organization today? Maybe all 3?

His suggestion:

• Commit to and trust your ability to respond.
• Stand in the fire and look to see what's true.
• Own it–what to do will become clear to you.

For those of you in the Portland, OR metro area you might be interested in attending the SAO Developers SIG on Wednesday Nov 30, 2005 at 7:30am. The topic will be Agile Development - The Academic and Industry Perspectives. I will be sharing the stage with Ward Cunningham and Greg Rose. My topic will be "The Agile Customer".
Hope to see you there.

Recently I have run into a number of people, both employees and consultants who can’t seem to separate themselves from their work while on vacation. This behavior is extremely mystifying to me. A related phenomenon is people who won’t/don’t use their vacation. I’ve identified 4 personalities that exhibit these tendencies.

• William the Worker doesn’t have a separate identity from his work identity and feels lost doing something different than work tasks.
• Essential Ellen believes that without her things will fall apart.
• Charlie the Consultant feels the need to work wherever he is because of the financial pressures of hours not worked being hours not billed.
• Hacker Helen loves her work so much she’d rather do it that anything else and typically works at home after work for "fun" regularly and vacations are no different.

Are you William, Ellen, Charlie or Helen? How do you justify working on vacation or not taking your vacation?

I'll be presenting a session on TDD at the 2005 Portland, OR Code Camp on July 23 at 11:15am.

I'll be in London next week (6/19-6/24) so if anyone wants to get together in the evening drop me a line.

Darrell pointed me to this site on International Addresses and the complexities therein.

Darrell is using this from a testing point of view, but I have been fascinated for years about how to design an effective solution for US based systems that need to deal with foreign addresses. This will be a great resource.

Patrick Logan writesabout the debate regarding whether software development is a craft or engineering. He has an interesting spin in that what makes software seem "craft-like" is the informalities.

I think the "informality" of software makes it feel craft-like. If only we had more formalisms. Could be, but we'll always have "informalities". Every engineering effort, and every creative effort in general, involves many informal conversations.

The difference is perhaps software depends more on informal conversations than do many of the traditional engineering disciplines. The requirements in those disciplines are more formal. Most of software development is really requirements development. The interpretation of formal requirements is most easily expressed in software as tests and code that (correctly one hopes) runs those tests.

Ultimately Patrick says that communications is the key and that failed is a result of failed communication not lack of formalism.

Which still begs the question for me - what is it that we, the software development discipline, are envious of from the "other" engineering disciplines?