Robby on Rails: Tag communication

Campfire messages in Growl

Robby Russell — Wed, 05 Mar 2008 16:24:00 -0600

Our team has slowly been transitioning from IRC to Campfire (iPhone interface helped with this decision) for internal team discussions. Earlier today, I decided to setup Campfire to connect to Growl. There are a few scripts to do this, but I figured that I’d consolidate the steps here for my teammates and share with everyone else in the process.

Step 1: Get stuff installed

You’ll need to install the following programs on OSX.

Growl (install and run it)
Fluid.app (run a web site in it’s own desktop app)
- Follow instructions on their homepage (requires restart of Safari)

Step 2: Setup Campfire

Once you have everything installed, you can go ahead and create your Campfire Fluid application. You’ll need to provide your Campfire URL and a name for the application.

Uploaded with plasq’s Skitch!

Once you get it running, you should be able to run your Campfire application in it’s own window.

Uploaded with plasq’s Skitch!

Step 3: Install the Campfire Growl script for GreaseKit

Next, you’ll want to install this script, created by Tim Harper, on userscripts.org within your Campfire Fluid.app instance.

Under the Userscripts menu, you’ll see: Browse Userscripts.org.

Uploaded with plasq’s Skitch!

Find your way to the script (search for: “Campfire Growl”) to find and install the script.

Uploaded with plasq’s Skitch!

Once it installs, you’ll then need to activate it in the Fluid applications management interface. Within Campfire application, go to Userscripts > Manage Userscripts.

Uploaded with plasq’s Skitch!

Then activate it like so:

Uploaded with plasq’s Skitch!

..and that’s it! When you’re not focused on Campfire… you should see Growl notifications when other people are talking in the active room.

Tip: Save your users 15+ seconds of their day

Robby Russell — Thu, 31 Jan 2008 12:42:00 -0600

Since understanding the context is so important when designing interfaces, I wanted to point out one of those things that caused me to shake my head at.

When logging into our Basecamp account this afternoon (via openid)... I was presented the following helpful notice.

Uploaded with plasq’s Skitch!

What’s amusing in this scenario… is that I’m sure that Basecamp knows that I’m logged in via openid and it is, in fact, displaying the OpenBar across the top of the page. Yet, it’s making this helpful recommendation that I’m obviously already aware of.

What harm is there? Well, in this scenario, I caught it and thought, “wow, this isn’t helpful or informative.” Over time, it’s these short-lived experiences that affect our overall perceptions of the product.

When we’re designing and developing applications, we must be very consistent with how we communicate with our audience. We don’t need to provide them information that isn’t relevant to them.

I’m not picking on Basecamp here, I’m sure that they have great intentions with this, but as a developer, I know that it doesn’t take a whole lot of extra work to avoid small problems like this, which could lead your people to feel like you’re not being respectful of their time.

Saving customers 15-30 seconds is something that we can quantify.

100 customers = 25-50 minutes
1,000 customers = ~4-8 hours
10,000 customers = 40-80 hours
etc…

Just a little reminder that it’s easy for us to overlook things like that can make a difference.

Embracing Failure, part 1

Robby Russell — Tue, 10 Apr 2007 16:38:00 -0500

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

In what ways is your team embracing the failures of your development projects?
How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

Poor Communication and IT Projects

Robby Russell — Mon, 12 Mar 2007 17:25:00 -0500

InformationWeek has a short story titled, Poor Communications, Unrealistic Scheduling Lead To IT Project Failure.

“Communications failures top the list of reasons IT projects fail, according to poll results from the Computing Technology Industry Association.

About 28% of 1,000 respondents identified poor communications as the main cause of project failure, according to CompTIA, which offers project management training.”

So, while we’re all spending so much of our time focused on improving our technical skills, are we also investing our time into becoming communication superstars?

If you look back at the following posts, you’ll see some links to some excellent books on this topic.

Seth Godin on Dialogue

Robby Russell — Fri, 09 Mar 2007 11:37:00 -0600

It appears that Seth Godin is catching on to the concept of Dialogue.

Seth writes, “Some organizations are good at listening. Some are good at talking. A few are even good at both.”

I’ve been spending a lot of time thinking about how I listen to clients, employees, friends, and family. All of our relationships are a series of conversations. Sometimes we can have healthy dialogue, sometimes we just fall victim to debate. (see Dialogue vs Debate)

If you’re really interested in Dialogue, I’d encourage you to review the technology of Dialogue... and check out the Dialogue-Driven Development project and introduce yourself.

Please Make Fun of the Boss

Robby Russell — Fri, 02 Mar 2007 00:26:00 -0600

While reviewing some articles related to small business management, I came across the following post… titled, Note From Boss to Employees, by Michael Wade. As a young business owner, who only 16 months ago was working in his attic… to now trying to figure out how to run a company with over ten employees (and growing), posts like this remind me that we all have so much to learn. :-)

Here are a few that I appreciated…

“I may not have been given a huge amount of training before being named to a supervisory position. As a result, I’ve had to learn through trial and error. That’s not always bad. Many of my responsibilities can only be learned through practice.”

Yep… that’s me! The only difference is that I promoted myself instead of being promoted by someone else. I’m still not sure what I got myself into sometimes. ;-)

“I will make mistakes. Please give me the same understanding that you’d like me to give you when you blunder.”

This reminded me of a blog post from last year, titled, Avoiding the most common software development goofs, which points out that things like ignorance and stress are often to blame for mistakes in development. I feel like these are reasons for goofs in just about any environment, especially business. Let’s face it. We’re not perfect and we’re going to make a lot of mistakes. Once we’ve agreed on this, let’s take the next step and see what happens.

“If I do something dumb or am on the verge of doing so, please tell me. Don’t hint. Tell me.”

Perhaps this is a common problem for most small business owners. Are employees afraid to tell me that I’m doing something dumb?

“If either of us has a problem with the other’s performance, let’s talk about it.”

As they say, real friends will be honest with you about your faults. Not because they want to make you look bad, but because they care.

Each of the points that I have listed here are pointing to is… healthier Dialogue, which is always a challenge to accomplish… in any relationship… whether with clients, coworkers, bosses, or employees.

I’d like to add a few to this list.

It’s easier to ask for forgiveness, than to ask for permission.
I’m still trying to get the hang of this GTD stuff, so.. you might remind me if I forgot something.
Ask yourself on a regular basis, “Am I having fun?” If not, make time for some.
Please make fun of the boss! :-)

On Apologies

Robby Russell — Thu, 15 Feb 2007 16:01:00 -0600

Recently, Seth Godin posted a short blog post, titled, Apologies, ranked, which points out several ways of apologizing. When you work in a service industry, it becomes very important to develop good apology skills. Let’s be honest for a moment. Not everything works out for the best in every customer experience. Sometimes it’s their fault and many times… it’s our fault.

In response to Seth’s post, Marc Chung has written up a similar post that adapts this to software bugs, titled, Seth on Fixing Bugs.

It’s worth a read and definitely relates to the communication issues that we keep talking about within the Dialogue-Driven Development community and how that can translate to a healthy testing process with BDD.

Thoughts?

Those that Tend the Store need Dialogue

Robby Russell — Thu, 04 Jan 2007 17:18:00 -0600

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!

Project Enlightenment with d3

Robby Russell — Wed, 27 Sep 2006 02:38:00 -0500

What do we mean exactly when we say that we want to participate in thoughtful dialogue in a project? What is our intention with this? When I recently came across some essays by David Gurteen and read his definition of dialogue as being “a disciplined form of conversation” it got me thinking about how we often forget that like all skills, practice makes perfect. What make our conversations discilplined in the first place? Based on my experience, dialogue (disciplined conversation) manifests when all participants in a conversation are practicing mindfulness. I don’t believe that most people learn or behave well by being beaten into submission, so we must come to an understanding while we actively involve ourselves in dialogue. Most of us are civil towards one another, which does wonders for allowing us to tolerate each other, but I still can’t help but feel that we’re still missing the mark when it comes to having consistent and thoughtful dialogue.

Over the past several months, our team has been spending quite a bit of time and energy analyzing these problems. What we really starting to uncover is that the real problem seems to exist somewhere outside of our development methodologies. Working under the Agile umbrella provides no silver bullet. The real issues seem to exist much deeper in our human nature.

We’re not all that great at communicating

Humans are not perfect… therefore… our ideas are probably far from perfect as well. Our thoughts aren’t perfect. Our interactions aren’t perfect. We’re consistently inconsistent (heh) and while we can rely on averages to some extent to calculate probabilities, we can’t always explain why somethings still go horribly wrong. The principles outlines in the Agile manifesto stress the importance of focusing on people not processes and responding to change. If we are to put a heavy focus on the people involved in projects, we must acknowledge our strengths and weaknesses and find innovative ways to improve our communication skills.

On a daily basis, we’re faced with complex problems. Hopefully, we’re using a lot of our prior experience to aid us in making rational decisions about how we respond to them. There is a lot that goes through each decision that we make. We can’t automate this process (yet), but we can definitely share our lessons with one another. Our intentions need to be thoughtful and empathetic to the needs of all parties affected by each decision. As humans, we have the opportunity to really listen to the concerns of others and use not only our logical intelligence… but also our emotional intelligence.

Much of this comes down to each of us learning to understand how we make decisions and interact with people. It’s our goal with Dialogue-Driven Development that with your help, we’ll be able to outline patterns of dialogue, which we hope will be of great value to the community. Our team has been analyzing our interaction with clients and discussing what has worked well and what hasn’t. How did our clients respond to approach X versus Y? It’s important that we capture this information and have conversations about the results.

“The meaning is what holds it [dialogue] together. ..Meaning is not static – it is flowing. And if we have the meaning being shared, then it is flowing among us; it holds the group together…in that way we can talk together coherently and think together.” – David Bohm

Doesn’t that sound beautiful? Who wouldn’t want to reach such levels of project enlightenment?

d3 aims to be to communication what BDD is to specification

While at RailsConf Europe, I had the privilege to speak with several Rail developers… several of which are doing contract development for several clients, just like our team. We discussed d3 for a while and I walked away feeling really excited about the whole concept. When I explained that our team didn’t see d3 as a replacement for Agile methodologies like Scrum, XP, etc… but as another tool in our tool belt. Dialogue between developers, clients, and users should be agnostic about particular methodologies. We’re really excited about Behavior-Driven Development as a best practice in our development process and we’re seeing Dialogue-Driven Development as another best practice that we start using from the initial point of contact with a potential client to long after we deliver the working product that we were contracted to develop.

We’ll be posting some fun announcements about the d3 project in the coming week(s). Stay tuned…