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. :-)

Courtenay has posted a step by step tutorial on using memcache within your Rails application. He not only discusses caching… but also how to _“precache the data so that each page load is blazing fast without sacrificing user experience._”

Read more about it on the caboo.se blog.

A few weeks ago, Brian Ford was in my office and we were discussing BDD and how we can make this process even easier for our clients to understand… much less our own internal staff. With all concepts, each person has their own idea about what it is, why it is important, regardless of whether or not it’s accurate. This can cause some people to not find a good need for some practices.

During our discussion, Brian grabbed one of my whiteboard markers and drew diagrams to explain how he saw BDD vary from TDD. He has since posted an article on his blog titled, what’s it worth to me, and discusses his circular view of Behavior-Driven Developent and the importance of using Dialogue to evolve shared meaning.

One of the coolest parts about my job (aside working with cool people everyday..). is getting a say in where we spend some of our money as a company. One of the things that Allison and I decided that we really wanted to do as a company was encourage sustainable business and growth in our local community. Everyone here loves Portland, Oregon.

This screenshot was taken after we took headshots for our transportation passes.

{width=”240” height=”150”}

Our awesome Office Manager, Nicole Fritz has started a blog, which she plans to, “…not only to let people know what goes on behind the scenes at PA, but to give other startups hints and tips about cool admin things that I have learned along the way (from taxes to how to get the right people “on the bus”).”

Nicole has posted an article, which introduces people to some of the great tax credits that small businesses like PLANET ARGON can take advantage of… in particular how we are now taking advantage of a tax credit for public transportation, bike storage, carpool programs, and more.

If you’re a customer of ours or are running a small business… you might consider subscribing to her feed.