Well, they must be listening to me.

A few months ago, I posted that I was looking to switch mobile services. Well, I switched over to Cingular after a lot of back and forth and have been fairly happy with their service. I opted to get their lowend/entry phone as I wanted to get a nicer phone when I found something that met my requirements.

I wanted…

• wifi
• bluetooth
• ssh client
• lightweight web browsing
• scheduling that sync’d well with ical

Well, I hadn’t found anything that really caught my attention. So, I heard rumors about Apple releasing a phone in January. So… I waited.

“Yay Apple! I think I’m in the right office, we’re all sitting here reading the keynote updates.” — Audrey

So, how much is this going to cost us? ..a few of us here came up with our predictions.

Thank you, Apple!

…well… I would have given Apple a hug if I didn’t have to wait til June.

…back to work.

Wow, this is pretty cool.

CDBaby is sponsoring conference passes AND twenty rooms at the Jupiter Hotel in Portland, OR during RailsConf 2007 to the top 20 contributors to the Ruby on Rails project from during January.

Start submitting patches!

During the summer of 2005, I wrote a post that listed several coffee shops in Portland, Oregon that I found to be really good places to work on your laptop at. I’ve gotten bored with my regulars and have recently begun to look for new places to venture to.

{width=”240” height=”160”}

Pier Coffee is in a weird part of Portland that is somewhat isolated due to the train tracks that will block you in when a long train is moving through town. It’s a very short walk from Allison’s place and they have Oregon Chai, which has become my replacement for drinking coffee. The chairs in Pier Coffee are very comfortable and they have an electrical outlet at most of their tables. When you get bored, you can walk over and play darts, or get a glass of wine. The wireless works really well and when it’s not raining, you can sit out front and overlook the train tracks and downtown, while hacking on your laptop. Pier Coffee is what I would consider an easy place for me to feel productive. There usually isn’t too many people here and I believe most of the customers are from the two condo complexes next to it. The staff is very friendly and their music tastes aren’t annoying.

Backspace is about a half block from the PLANET ARGON office. They don’t serve Oregon Chai, so I usually only get a tea, a viso, or a hot cocoa while there. They have a few tables and couches and I haven’t found this a good place to be productive. It’s a good place to have a short meeting with a coworker though. Music tastes are better here than most places, and they have a food menu now that caters to my vegetarian diet. There are a few electrical outlets, but the seats near them are often occupied.

Three Lions Bakery is about a block from the PLANET ARGON office. They do have Oregon Chai, so I stop by here often in the morning to get my fix. Not many electrical outlets, so your visits are usually not very long. They have a few sandwiches that are quite good. This is a good place to stop by if you’re in the mood to work for about a hour and have some chai and an excellent (and freshly baked) cookie.

If you’re in Portland and have some recommendations, please do share. I’m looking for a few places that are open later in the evening.

I’ve been keeping my eye on a series of blog posts by Chad Fowler, which he calls The Big Rewrite.

Today, Chad posted an entry titled, Who’s Tending the Store? He writes…

“the experts keep the old system running while the new system is being built. So, who builds the new system? Not the experts, that’s who. Usually, it’s people like me: technology experts. And while we’re banging away at the existing system’s UI, trying to figure out what needs to be coded, the domain experts are doing their jobs. Unfortunately, this means the domain experts aren’t watching the Big Rewrite very closely. Regardless of how good the team, if communication is impaired between the domain experts and the technology experts, things are going to move slowly, and wrong software is going to be created.”

I wanted to follow up on this issue as it’s an area of great interest to me.

I feel like this issue runs deeper and while it’s important to be mindful of the communication between domain and technology experts, it’s a good idea for each of us to take a break every few days (or everyday) to assess our perceptions in all areas of the project. More specifically, I’m suggesting that in order for us to be effective in our communication, we must make time to refactor our perceptions about the state of a project. From the design, to the development, to team communication, to the schedule, and all the way to customer satisfaction… or what Martin Fowler calls, Customer Affinity. These things are not static and we must see them as extremely dynamic variables… much more dynamic than our wonderful language of choice.

When Brian Ford and I started discussing Dialogue-Driven Development (d3), we were initially focused on an area that always seems to come up in projects. Client communication. From managing expectations to delivering the right product, d3 has become an essential tool in our team’s tool belt. We refactored our entire Design and Development process (and it’s always evolving) to focus on the things that we felt were the most important to a successful project. Clients come to us in search of expertise and guidance so that we can build them innovative solutions. When it comes to this process, clients deserve simplicity.

For starters, we’re misguided

If there is one thing that I have learned, it is that our initial perceptions are often misguided. We have to work really hard to think critically, not only of the problem we’re trying to build a solution for, but also of how we, ourselves, are actually looking at the problem. It’s easy to fall victim to tunnel vision. I often find myself having to take a step back from problems on a very regular basis. While I have no scientific proof to back this, it seems to feels natural for us to keep firing once we pull the trigger. It’s important to re-aim.

Chad raises a very important topic and leaves readers to think about the problem. After thinking about this, it’s my opinion that in order for the domain and technology experts to be effective, they need healthy collaboration. But, I feel like this applies to many other areas of our process as well.

Is there even a problem?

So, what is the solution? Better yet, what is the problem? Is there even a problem?

How can we avoid situations where communication becomes impaired? We’ve all been there. We know how to spot impaired communication, but how can we spot it… before we perceive it as too late? How can we recover from it? What causes the communication to break down? What if… it were possible to repair the situation?

These questions don’t have easy answers. These are complicated problems that reach far beyond the development community. These are the same problems that all members of organizations, communities, countries, and planets all face, each and every day.

Take action!

While it’s important to make sure we’re engaging in healthy dialogue through a project, bad things will happen. They are inevitable. As Agilists, we’re accepting this as a fact of (project) life and should be prepared to take action. If you see communication being impaired, it’s time to step up and help the team out. Otherwise, you’re only hurting yourself… and your colleagues.

“Be the change you wish to see in the world.” — Mahatma Gandhi

If these sorts of topics are of interest to you, I encourage you to join the Dialogue-Driven community and help us figure this stuff out!

Finally, a break from a hectic week at the office. I spent most of my week working on some servers and outlining some of our plans for where we will be taking the hosting side of our business during the first quarter of 2007. Let’s just say, we’re a few months behind schedule and it’s time to get onboard before the train takes off. ;-)

{width=”240” height=”160”}

Have a safe and exciting New Years!

Yesterday, those of us who were still at the PLANET ARGON office (and not already on vacation) took the afternoon off yesterday to have a few drinks to kick-start the holiday season.

{width=”240” height=”188”}

{width=”240” height=”160”}

{width=”160” height=”240”}

I’m getting ready to head up to Seattle for the holiday weekend. I hope that you all have a safe and fun holiday season!

Where have I been the past month?

In a nutshell… I’ve been working, writing, and trying to start a new music project[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”}.

It’s almost the end of year and things have been extremely busy at PLANET ARGON. You might notice some new names on our site as we have been doing some growing. I’ll announce those individuals at a later point in time… but a quick peak at our Flickr page should give you some insight. :-)

Earlier today, we announced that we’ll be having a special deal on our Rails hosting from now until the end of 2006.

If you’re looking for a good platform to host your Rails applications, we currently recommend the following configuration.

• [Mongrel

Cluster](http://docs.planetargon.com/wiki/show/Pound+and+Mongrel)
(at least 2 mongrel instances)
```bash
-   Pound as a load balancer/proxy ([Nginx is also
```text
available](http://docs.planetargon.com/wiki/show/Setup+Nginx) for
all customers!)
```text
-   [Capistrano for automatic
```text
deployment](http://docs.planetargon.com/wiki/show/Use+Capistrano+at+PLANET+ARGON)
```ruby
These are offered on both our
[shared](http://www.planetargon.com/hosting.html) and
[business](http://www.planetargon.com/rails_business_hosting.html) Rails
hosting plans. We've also been revamping our technical support options
the past month, so take a moment to review our current [support
options](http://www.planetargon.com/support.html).

We're looking forward to 2007! In two months, it'll be two full years
since we [first
announced](http://blog.planetargon.com/archives/38-Rails-Hosting.html)
support for Rails hosting!

------------------------------------------------------------------------

1.  ::: {#fn1}
```yaml
For the record, H.O.T was a silly project from several years ago...
check our our holiday ep\![↩︎](#fnref1){.footnote-back
role="doc-backlink"}
:::

Let me just say… that our customers are awesome.

One of our favorite customers, Timothy Bennett, has posted some documentation for running Nginx on your PLANET ARGON hosting account. If you’re already playing with mongrel, lighttpd, and pound…. you might look at Nginx.

“Nginx is a proxy/load-balancer that also is able to serve static files (and is a good deal faster at it than mongrel). It’s more complicated to setup than pound, but results in a faster setup.”

Stop by our new online forums (powered by Beast) and/or our IRC Channel to meet some of our great customers!

This was from a discussion a few weeks ago on the Dialogue-Driven Development mailing list.

Bob listed five things that promotes dialogue.

1. Active Listening
2. Agenda Control
3. Trust
4. Follow-Up/Follow-Through
5. Don’t Over Promise

“Don’t Over Promise; In business, it seems about half wait until the last minute and the other half hasn’t a clue about what’s really involved in making any sort of quality effort at something (look at the dismal record on software project performance in the CHAOS report and others). If you overpromise/underdeliver against expectations; you’ll damage both trust and future dialogue. Don’t commit to situations where there’s any doubt in your mind regarding your ability to perform. It doesn’t matter as much about capability (since we all like the challenge) as much as it does about raw capacity (in terms of time) to perform within the established timeframe.”

The list has been about as dormant as my blog has the past several weeks. I’m currently reading through King Arthur’s Round Table, by David Perkins, which focuses on different conversation styles and Dialogue: The Art of Thinking Together, by William Isaacs. I hope to share some of what I learn on my blog and with the list. :-)

I missed a week… but last week, Brian wrote about one of the Principles of d3: simplicty.

“As a principle of d3, we want our client interaction to be simpler. So we want to talk about problems with our clients. We want these to be the concrete, explicit elements we dialogue about.” (read more)

Today, I asked on the Dialogue-Driven Development mailing list, “What are some elements in group interaction (clients, colleagues, users) that prevent healthy Dialogue from taking place?”

“The biggest element that I’ve seen that harms dialogue is an emotionalattachment to some idea or decision… …When people are emotionally attached to one particular point of view, they have a difficult time making objective, rational decisions.” —David Goodlad

“The biggest problem that we have is semi-literate users thinking too soon about implementation details about the solution, rather than considering the true nature of the problem instead.” —James Adam

This resulted in me thinking up a new term for this horrible infection… implementitus.

“One of the biggest problems I’m continuously having to overcome is physical proximity. I’m a firm believer in kicking off a project with a face-to-face meeting, but when working remotely, and not having an on-site customer to easily communicate with your skills has a communicator must be greatly increased.” —Josh Knowles

“Fortune-telling the user’s reaction.

“The user wouldn’t like this.”

“This user wants this button there.”

“That would confuse the user.”\

Of course, user opinion should be critically important, but in my experience it’s often used as a veto that doesn’t have to be explained just because someone doesn’t like an idea. I’ve done this, myself.” —“Brasten Sager”:http://www.ibrasten.com

I’m really excited to get the interact with other people who are facing the same types of obstacles that we are. Being a successful developer requires a lot of discipline and it’s our goal to enhance our communication skills… so that we can reach shared meaning with our colleagues, clients, and users.

If developer to client, developer to developer, or developer to user interaction is important to you… come talk with us in the Dialogue-Driven Development project.

A few weeks ago, I was explaining some of the concepts behind Dialogue-Driven Development to Michael Buffington and when I said that we were working to create patterns of Dialogue. his immediate thoughts were on code. I don’t remember the exactly how he worded it.. but he basically thought we were working on a parsing tool for grabbing requirements out of emails, messages, etc. I quickly explained that d3 had nothing to do with actual code and was merely a practice that we as developers and consultants are using to think about our interaction with clients, users, and amongst ourselves.

Just last night, I was chatting with a friend of mine about d3… (names changed to protect the guilty)

context: Harry works in a development team[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”} of about ten people and Paul is one of his “team”mates.

Just happened to notice that RubyURL passed the 10k mark recnetly. :-)

“10044 happy rubyurls to date”

I think it’s time for a rewrite and an API. :-)