Robby on Rails: Tag clients

Tip: Link to Unimplemented

Robby Russell — Thu, 27 Mar 2008 06:10:00 -0500

Throughout our design and development process, we’re working around areas of the site that are not yet implemented but we also want to be able to allow our clients to demo their application. In an effort to manage their expectations, we need to be careful about what we link to. If a page/widget isn’t ready to be demo’d yet, we should avoid providing pathways to get interact with or navigate there. However, when we’re implementing HTML/CSS for pages, it’s sometimes makes sense to not hide certain things on the screen.

For example, let’s suppose that you’re working on the primary navigation of an application. You know what the other sections are going to be, but you’ve only implemented a few of them so far. Your HTML/CSS person is working on the design for the navigation and wants to have them be proper links… even to pages that don’t yet exist.

One option, which is quite common, is to provide a link with href="#". This works to some extent, but when people click on things, they naturally expect something to happen in response.

This approach doesn’t mesh well with our team as we don’t really want to field any questions like, “the navigation links are all broken. Nothing happens!”

So, a pattern that we’ve been using for a while is to trigger a javascript alert for every link within an implemented area that is linking to something that isn’t yet implemented.

Let’s take a really basic javascript function like:


# public/javascripts/application.js
function unimplemented() {
  alert("NOTICE\n\nThis feature is not implemented yet. Please check back again soon!");
}

This allows us to do the following:


  <a href="javascript:unimplemented();">link text</a>

When someone clicks the link, they’ll see a typical javascript alert message. This informs our clients/beta testers that we’re paying attention to what works and what doesn’t.

Uploaded with plasq’s Skitch!

Let’s take it a step further and push this into a view helper.


# app/helpers/application_helper.rb
def link_to_unimplemented( link_text, *args )
  link_to_function( link_text, 'unimplemented()', *args)
end

Now, we’re able to use link_to_unimplemented and pass any arguments that you’d pass to the default link_to view helper.


<%= link_to_unimplemented( 'link text', { :class => 'link_class_name' } ) -%>

Now our web designers can go about their work and use this helper as necessary.

An nice benefit for doing this is that we have a pattern that we follow so that we can rely upon to make sure that we don’t forget anything. This is the equivalent of adding @TODO@s throughout our code base.

If we search through app/views for ‘link_to_unimplemented’ we should be able to prevent missing any broken links. In the next screenshot, I’m using grep with colorized matches.

Uploaded with plasq’s Skitch!

As you can see, we have something left to implement in that area of the application. :-)

This has been one of those lightweight patterns that we’ve been able to adopt and it’s definitely helped manage the expectations of our clients throughout our development process.

I’d love to hear your thoughts on this. How does your team handle things like this?

Embracing Chaos, part 1

Robby Russell — Mon, 17 Dec 2007 22:21:00 -0600

Consider this part one of several posts on my thoughts of the art of embracing chaos.

Don’t let the books fool you. The construction of custom software is an unmastered and volatile cesspool of chaos. I don’t adhere to the belief that there is a perfect methodology or process that will work for every project… as I’m sure many of you don’t.

Unlike bowling, you’ll never achieve a perfect score. Even in bowling, It’s unlikely that anybody will learn how to bowl a perfect score and do so on every game for the rest of their career.

You’ll never meet every expectation that a client has on every project.

You’ll never meet every expectation that a user has when they interact with your application.

Expectations are an interesting thing.

Your project might get widely adopted and embraced, but you’re still trying to control chaos.

It’s chaos. Pure chaos¹.

So, why do we bother? Why do we try so hard when the odds aren’t in our favor?

To be continued…

¹ Chaos Theory, Wikipedia

Rails Business: "Weekly" Review #3

Robby Russell — Sun, 05 Aug 2007 10:37:00 -0500

It’s been about six weeks since the last Rails Business “Weekly” Review on here, so perhaps it’s worth changing the name to cut me some slack on not being consistent. ;-)

Since the last post, we’ve gone from around 400 members to 555 as of this morning. We’ve had 562 messages as well, so there hasn’t been a shortage of discussions taking place. I’d like to take a few moments to highlight some of the discussions that have taken place and encourage you all to consider participating, if you’re not already.

Licensing and Client Agreements

Tim Case writes,

“My client sent me this agreement drawn up from their lawyer that included the following:

(c) the Contractor shall not bundle with or incorporate into any Work Product any third-party products, ideas, processes, software, codes, data, techniques, names, images, or other items or properties without the express, written prior approval of the Company;”

Tim then goes on to ask how his applies to using Ruby on Rails, which as a MIT license and how other consultancies are handling these types of situations. Follow the discussion…

Escrow

Gustin writes, “Does anyone have any escrow experience, legal and cost? I am dealing with a client that got burned bad and we are reducing their fear with escrow on the first two iterations.”

Follow the discussion…

Project Planning tools

Mike Pence writes, “So, I used to use MS Project for the composition of those dreaded Gantt charts, but it has been a few years since I had to be so formal. Anything new and exciting – and more robust than Basecamp – happening in the world of project planning software?”

Follow the discussion…

Not long after, Jim Mulholland started a new thread on the same topic and brought up the open source application, redMine. Follow this discussion…

Ruby on Rails versus .NET

Michael Breen asked a big question on the list, which has sparked an going discussion about the benefits of using Rails versus .NET (and other platforms).

“A couple of months ago I decided to stop actively pursuing .NET gigs to focus on Rails. Several of my existing .NET clients have learned of this through the grapevine and have contacted me to discuss.”

Follow the discussion…

Three things Tim’s learned from Freelancing Rails

Tim Case shared his experience of freelancing with Ruby on Rails and highlights three things that he’s learned.

The non-code business aspect of Freelancing is demanding.
It takes 10 hours to bill 6 to 8.
Figuring out your rate is hard.

Read the rest of Tim’s observations and the discussion the followed.

Client issue tracking and documentation

Jeff Judge writes, “Hello all! I was curious to here how people are handling client issue tracking and documentation.”

Several applications were mentioned for handling issue tracking and the general consensus was that there was still a lot to be desired that current options didn’t provide. Be sure to follow the discussions…

Join the Community

These were just a small handfull of the discussions that have taken place over the past several weeks. If you’re an aspiring Rails freelancer or business owner, be sure to join the community and share your experiences and learn from other members of the community that are willing to share theirs.

Until next time, have fun!

Rails Business: Weekly Review #2

Robby Russell — Mon, 18 Jun 2007 01:26:00 -0500

First of all, I’d like to welcome the more than fifty people that have joined the Rails Business group since my last post. Over the past week, there were less posts, but we did cover a few important topics, which may be of interest to you.

Subcontracting

Michael Breen asked a few questions about subcontracting for larger firms and how people set their rates when doing this. Several of the responses provided some personal experiences (good and bad) of being a subcontractor on large projects. Where some risks are and how to negotiate your rates, when applicable.

Read the discussion

Change Requests

Nick Coyne started a discussion on how to manage change requests in an Agile development process.

Dealing with large clients

There was also a discussion about how to go about responding to a 150 page RFP for a large client. A few of us offered our experiences of bidding on large projects. Read more

Join the Community

The list is about to pass 400 members and it’s already proving to be a valuable resource for all of you entrepreneurs out there. I encourage you all to introduce yourself.

For more info: http://groups.google.com/group/rails-business

Rails Business: Weekly Review #1

Robby Russell — Sat, 09 Jun 2007 17:07:00 -0500

This past week (give or take a few days), the Rails Business group has covered a lot of topics, that might be of interest to you, should you be running a business and using Ruby on Rails. Many of the members of the new group are independent contractors and have been very open in sharing their experiences of working for themselves. I’d like to take a moment to highlight a few conversations and tips that were covered this past week.

Health Coverage

Mike Pence started a conversation about health coverage…

“Has anyone else found the medical insurance issue to be a show stopper for them? Are you one doctor visit and diagnosis away from financial ruin? I can tell you firsthand that wishful thinking won’t pay those bills…”

This started a discussion about how people are able to work on their own and maintain health coverage, which is definitely not something that should be considered lightly. Read more…

Client Expenses

Another great question was raised by Mike Breen.

“I’m going to start work on my first project that will require me to travel. How should I handle the expenses? Do I build the costs into the contract price or do I submit the expenses to the client for reimbursements? Or does this vary from client to client based on the company policy?”

The responses included links to IRS sites and sections of other peoples’ contracts. Read more...

Hosting Client Repositories

Where do you host your client’s source code repositories? Are you managing it all yourself on your own servers or using a service?

The discussion (so far) has lead us to evaluate our own solution for this at PLANET ARGON. It appears that everyone has different concerns about how they want to manage client code during the development cycle.

For example, do you allow your client access to trunk/ if they aren’t all paid up yet?

Also, it seems like there are a bunch of new commercial options coming out (and are built on Rails). Read more...

Naming Your Business

Jared Haworth writes,

“For those of you who are working as ‘independent developers,’ have you found that it makes more sense to simply do business under your own name, for example “Jared Haworth L.L.C.,” or to come up with a clever business name instead, such as “Code Fusion Studios”?”

This was a good conversation to follow and definitely raised a lot of great questions and things to consider in response to the original message. Read more...

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…

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!

Teams Need Healthy Collaboration

Robby Russell — Wed, 18 Oct 2006 10:05:00 -0500

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¹ of about ten people and Paul is one of his “team”mates.


  Harry: i guess it prevents discussion domination
   me: yeah, that happens as it is sometimes
  Harry: and ensures equal contribution
  Harry: paul does that 
    and he's not very polite about it either
    and will often raise his voice and speak over you
    which is crazy
    kindergarten stuff
  me: hah
  Harry: need a talking stick!

This happens all too often amongst ourselves. While we’re striving to improve our client interaction… we often overlook our own internal struggles to achieve healthy collaboration. It takes discipline by every individual in a collaborative environment to really think together.

So, how does d3 address this? Well, it’s our goal that through mindful dialogue, we can cultivate healthier collaboration in all of our professional (and personal) relationships.

I would also like to point out a few common misconceptions about d3.

d3 is not a methodology… nor a replacement for Scrum or XP. d3 is a thoughtful practice that focuses on the collaboration between a group of individuals, whether they be clients, developers, managers, or users.
d3 is not a Silver Bullet, but it can be used as effective ammunition.
d3 is not something you learn in a weekend, but you might be able to find a good book on Dialogue and have a new perspective on how you communicate with others.

Dialogue-Driven Development is about being in the conversation as it is happening… and really listening.

The next time that you’re getting ready to interact with your teammates, ask yourself:

Am I contributing something meaningful?
Am I listening to others well?
Is everybody contributing an equal share of information?

If you’re quiet, try to speak up more. If you talk too much, be mindful of how much you may dominate a conversation. If you’re not participating at all.. why are you there?

¹ You’ll be happy to know that Harry also gave his two-weeks notice yesterday.

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…

Matz on Considering Interface

Robby Russell — Mon, 25 Sep 2006 10:11:00 -0500

...back in Portland after being in London and New York City for the past two weeks. It’s nice to be home. :-)

I came across this interview with Matz earlier today. It was published almost three years ago (pre-Rails)... I’m quite intrigued by what he is advocating here…

Bill Venners: You also mentioned in your ten top tips: “Be nice to others. Consider interface first: man-to-man, man-to-machine, and machine-to-machine. And again remember the human factor is important.” What do you mean by, “consider interface first?”
Yukihiro Matsumoto: Interface is everything that we see as a user. If my computer is doing very complex things inside, but that complexity doesn’t show up on the surface, I don’t care. I don’t care if the computer works hard on the inside or not. I just want the right result presented in a good manner. So that means the interface is everything, for a plain computer user at least, when they are using a computer. That’s why we need to focus on interface.

Some software people—like weather forecasters, the number crunchers—feel that the inside matters most, but they are a very limited field of computer science. Most programmers need to focus on the surface, the interface, because that’s the most important thing.

Bill Venners: You also mentioned machine-to-machine interfaces, so are you just talking about interfaces for users or also for machines?

Yukihiro Matsumoto: It’s not just user interfaces. When machines are talking to each other via a protocol, they don’t care how the other is implemented on the inside. The important thing is the proper output getting passed correctly via the proper protocol. That’s what matters.
If you have a good interface on your system, and a budget of money and time, you can work on your system. If your system has bugs or is too slow, you can improve it. But if your system has a bad interface, you basically have nothing. It won’t matter if it is a work of the highest craftsmanship on the inside. If your system has a bad interface, no one will use it. So the interface or surface of the system, whether to users or other machines, is very important.

One of things that we’re really advocating with Dialogue-Driven Development is artifact generation. Wireframes and lightweight prototypes are great for generating constructive dialogue between clients, users, and our team. We should make sure that we understand why and how users will use an interface before we worry about the code that will drive it. Too often we fall into a pattern of thinking where we’re convinced that we can build an agnostic application that has various interfaces to a central repository of business logic and data. While we strive for this during development, it really should be focused on after some initial interaction design has been planned. Of course, this is my opinion.

So, I must ask you. When you’re working with on a new project, do you focus on interface or code implementation first?

The Technology of Dialogue

Robby Russell — Tue, 12 Sep 2006 14:30:00 -0500

In the essay, Dialogue and Organizational Transformation, Glenna Gerard and Linda Teurfs outline the the building blocks of THE TECHNOLOGY OF DIALOGUE, which they suggests consists of:

Suspension of Judgment
Identification of Assumptions
Listening
Inquiry and Reflection

What makes dialogue different than conversation? According to David Gurteen, “dialogue is a disciplined form of conversation.”

Gurteen says that within dialogue¹:

You prefer a certain position but do not cling to it.
You are ready to listen to others.
Your mindset is not one of ‘convincing others that your way is right’ but of asking what you can learn from them.
It is recognizing that other people’s input will help you refine your own ideas or reveal your misconceptions.
It is not argument or debate. It is not win-lose. In dialogue all sides win by coming up with a more appropriate solution than a single person could ever have. It is win-win.

When we first introduced Dialogue-Driven Development, Ryan Allen responded with a brief overview of how you might go about defining a failed project. His first bullet was, “Miscommunication can lead to the implementation of the wrong solutions.”

It is our opinion that many of the problems that lead to failed projects can be solved through consistent and cooperative discourse. Much of this relies on each of us taking ownership of our commitment to encouraging healthy collaboration between developers, clients, and users.

Wikipedia currently describes dialogue as, “a reciprocal conversation between two or more persons.”

Question

What are some of the obstacles that you face when interacting with a diverse set of developers, clients, and users?

¹ The Discipline of Dialogue by David Gurteen

Dialogue-Driven Development is about Listening

Robby Russell — Fri, 25 Aug 2006 19:11:00 -0500

I know. I know. I recently wrote that Dialogue-Driven Development was about rounded corners. It just happens that I also think that d3 is more than that. d3 is focuses on the conversations between various stakeholders within a project.

What is dialogue?

an exchange of ideas or opinions on a particular issue, esp. a political or religious issue, with a view to reaching an amicable agreement or settlement¹.

What is a conversation?

informal interchange of thoughts, information, etc., by spoken words; oral communication between persons; talk; colloquy²

Let’s focus on a really important side of the conversation, which is the art of listening.

In Information Anxiety 2, Richard Saul Wurman lists five tips for being a better listener.

“Having two ears and one tongue, we should listen twice as much as we speak.”
“Don’t try to formulate your reply when the other person is speaking.”
“The person who starts a sentence should be the one to finish it.”
“Don’t let your fear of silence propel you to fill it with air. A moment of silence can be the most revealing part of a conversation.”
“Remember that listening is not a passive endeavor, but an activity that requires great energy. Try to listen with the same intensity you use to talk.”

The Value in Face to Face

It’s been a while since we at PLANET ARGON have started working on a project that we didn’t get a chance to meet face to face with the client. For projects that we know will involve a lot of dialogue, it’s an absolute must at the beginning of the project. This is exactly why Brian and I fly across the country to meet our clients in person.

Wurman writes, “Time and time again, studies have shown that the best communication occurs face to face.”

“Precision of communication is important, more important than ever, in our era of hair-trigger balances, when a false, or misunderstood word may create as much disaster as a sudden thoughtless act.” – James Thurber

Our team is still shaping how best to encourage and facilitate valuable patterns of dialogue with our clients. One aspect we are certain of is that all interactions should be clearly documented, including the subtleties of body language and how the client’s team works together.

Two Ears, One Mouth

There are many benefits to having two ears. We should all try to listen more. I’ll be the first to admit that this is one of the most difficult things to do, especially when you’re opinionated.

“We have two ears and one mouth so that we can listen twice as much as we speak.” -Epictetus

The next time we find ourselves in the middle of a conversation, let’s try to listen more. :-)

¹ http://dictionary.reference.com/search?q=dialogue

² http://dictionary.reference.com/search?q=conversation

Information Anxiety and Solutions

Robby Russell — Tue, 22 Aug 2006 13:15:00 -0500

Last week, Allison brought me in a copy of a book that she owns by Richard Saul Wurman. In 1976, Wurman coined the phrase, information architect. (read more)

In his book, Information Anxiety 2, Wurman discusses how we’re overwhelmed by too much information… amongst other related topics.

Allison bookmarked a page for me that discusses the problem with developing solutions without a good understanding of the problem.

“Before any solutions to any undertaking can be developed, a movement must begin to discover its beginning. Understanding the vein of the problem is the course to solving it. The best way to accomplish any endeavor is to determine its essential purpose, its most basic mission. What is the endeavor supposed to accomplish? What is the reason for embarking upon it? This is where the solution lies.”

- Richard Saul Wurman, Information Anxiety 2

Wurman then goes on to suggest, “There are two parts to solving any problem: What you want to accomplish, and how you want to do it. Even the most creative people attach issues by leaping over what they want to do and going on to how they will do it. There are many how’s but only one what.”

There are many how’s but only one what

“You must always ask the question, “What is?” before you ask the question “How to?”“

When Brian and I began rethinking how we were extracting information from our clients, it was important to understand why we felt it was necessary. We’re convinced that the more we can enhance our patterns of dialogue with our clients, the more confidence we’ll have in our approach to building solutions that provide them with that they need, not just what they think they need (want).

Next time a client brings you a list of features for their product, please be sure to ask yourself and your client, “why” the product needs them. What are these hows providing their business and user goals?

Project Illuminatus, an introduction

Robby Russell — Mon, 14 Aug 2006 19:52:00 -0500

Due to an unfortunate event last week, this blog entry is a few days late.

Over the next few weeks and months, the PLANET ARGON team will be blogging about one of our big projects that recently started. We needed to get the client to sign off on the blogging project and got the a-okay from their management early last week.

First, some background.

We were contacted by this rather large (enterprise?) company around the time that we went to RailsConf. When we got back, I began talking with our primary point of contact about their project, which sounded like a fairly big challenge and the sales process took a few weeks to come to an agreement on the next steps. Once they were finished interviewing a few other potential firms, we got the go-ahead that we should proceed with an ITER-ZERO, which I outlined a few months ago in part one of, The Art of Delivery.

ITER-ZERO was essentially a two-day trip for Brian and I to Washington DC (pictures) to interview the client and some of their existing users (domain experts), establish the protocol and channels for communication between them (the client) and our team, and work on identifying the core goals of their product that we’ll be developing with them. They have an existing product that they’ve been selling to customers for over ten years and the product that we’ll be developing will be the next generation of this software. The new product is replacing a desktop application that is only runs on Windows. The application that we’re currently working has a technical requirement that is needs to run on any operating system with a modern web browser, including some of the newer phones that have Opera mini installed! As you can see, we have our work cut out for us… :-)

During our meetings, we agreed that while their final product name is going through their marketing process, that we should have a playful project name to refer to. Our primary contact at the firm suggested, Project Illuminatus[1]. He’s a bit of a conspiracy theory nut… and it sounded fun… so we agreed to that. :-)

If I recall, Brian and I stayed up past 2am (the time zone change does that to you…) working on structuring the project wiki (instiki) to document the dialogue that occurred on our first day in DC. This provided us with a solid plan for how we wanted to focus our attention to identifying the goals that we wanted to collaborate on with the client to build an innovative and simple to define solution. Simple solutions emerge from even complex goals when you can clarify them using simple and intelligible language.

In this great blog interview, Stiff asked several famous developers the following question, “What do you think makes some programmers 10 or 100 times more productive than others?”

David Heinemeir Hannsson responded with, “The ability to restate hard problems as easy ones.”

On day two, we showed their team the wiki and explained how they could collaborate with us there. If they had ideas and new goals identified, they had a place to store those. It’s vital that your attention is on the scope of the work that needs to be investigated. We try not to solve all of the problems too quickly… it’d be naive of us to think that we could. Products evolve and so must their requirements.

I’m not going to go into everything that went on here at the moment, perhaps Brian will fill us in on some of this.

When we got back to Portland, Brian and I began meeting with Allison Beckwith, our Creative Director, to outline one of the most complex pieces of the system. As a team, we decided that this is what we need to focus more of our immediate attention to. In the their previous application, there was approximately five different modules that did something very similar, but just slightly different enough for their original developers to just build separate interfaces, which were not consistent and difficult to use for someone new to the application. We want to consolidate this into one new solution that focuses on how the users will be using the system… not just the tasks that they are fulfilling. This is why we spend so much time thinking about the goals that the users have… not what they have to do.

Oh yeah… one of the non-functional requirements?

“The product shall be easy to use on the first attempt by a member of the general public without training.”[2]

About a week later, we agreed on what work would be performed during ITER-001 (iteration one), which included paper prototyping and a few rounds wireframe mockups for this one major component of the application. I’ll let Allison Beckwith (yes! she started a blog) fill you in on this when she gets some time to outline her process for doing this.

Stay tuned…

¹ http://en.wikipedia.org/wiki/Illuminatus

² copied directly from Mastering the Requirements Process, 2nd edition. It works.. and does it need to be reestated any simpler than that?

Dialogue-Driven Development is about rounded corners

Robby Russell — Sat, 05 Aug 2006 10:49:00 -0500

In response to our introduction of Dialogue-Driven Development, mechanismalley.com writes, ”...it seems to be the Rails community’s pattern to take an existing concept — or misconception — put rounded corners on it and deem it something new.” (link)

I’m not sure that I can completely agree with this generalization. What I’ve witnessed as a member of the Rails community, is an attempt to simplify code, solutions, processes, and as a result… conversation between developers and clients has become much richer and coherent. Take this with a grain of salt as this has only been my experience. Complex solutions are complex to explain and often too complex to know if they are actually solving the right goal. On the other hand, simple solutions make way for better dialogue. With Ruby on Rails, we are provided with a foundation that encourages and embraces best practices and simple solutions (rounded corners?), which makes it easier to discuss with the client. This is what fascinates me about Ruby on Rails… and what Martin Fowler in his keynote at RailsConf.

Perhaps it makes sense that what Brian and I are outlining with our approach to defining patterns for client<->development team interaction evolved through us working with Ruby on Rails. However, there is nothing that requires Rails in order to follow the patterns that we’re discussing. In Brian’s first article about d3, he referenced the following…

“What we are seeing is a drive toward simplicity. Conventional wisdom once was “quick necessarily means dirty”. Ruby challenges that.
—Martin Fowler

At the very core of our approach with Dialogue-Driven Development is the Agile Manifesto. The author of this post is correct, we’re taking an existing concept and putting rounded corners on it. We’re trying to make it simpler. We find that Scrum is too process heavy and while we can see it being a good step away from the Waterfall approach, it’s still not giving us that warm and fuzzy feeling. Rails developers know what that warm and fuzzy feeling is… and we are hoping to find something that gives our clients and us the same feeling when we’re not coding. We want lightweight methodologies to complement our lightweight frameworks and patterns.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

—The Agile Manifesto

It’s time to start rethinking how we work with clients. Too often we end up working for them and while we might build them what they want… we might not be giving them what they need.

So, I must ask… has working with Ruby on Rails reshaped the way you think about client and developer conversation? If so, for the better or worse?

High traces of collaboration and dialogue are usually found in the recipe of any successful project.

One cuckoo flew over the nest, Brian Ford
Dialogue-Driven Development
Dialog driven development is the real agile, Damien Tanner
Dialog driven development, Lazy Coder
It’s all about the dialogue, Brian Ford

DDD (d3) is the new conversational software development

Robby Russell — Thu, 03 Aug 2006 22:28:00 -0500

I’m not sure how I missed this recent post on Martin Fowler’s bliki last week on Customer Affinity. In this post he references when the term “agile” first came about and mentioned that, “one of Kent’s suggested names for ‘Agile’ was conversational software development – the point being that it’s a two way communication. “

Conversational Software Development.

This doesn’t sound so different than what Brian Ford and I are calling, Dialogue-Driven Development. ;-)

Fowler goes on to say, “This isn’t something like a telecoms protocol that you can define, but the back and forth discussions about how software can enhance the business are where the real value lives. Much of this conversation is of half-baked ideas, some of which grow into valuable features – often ones that aren’t things that the customer originally thought of.”

If you didn’t follow the thread of comments on my recent post on Dialogue-Driven Development, you might not know that this name came up during Martin Fowler’s keynote at RailsConf when Brian and I were sitting next to each other and Martin kept reusing the word “dialogue.” Brian and I can’t seem to agree if I said, “Dialogue-Driven Development” out loud or if he wrote it down on a piece of paper first… so we’re going to have to share the credit. What made this so fascinating at the time was that for the entire trip from Portland to Chicago on the Argon Express, Brian and I had been discussing a lot of what we’re planning to change and define with our approach to Client/Project/Development Collaboration & Management… and in the end… we left Chicago with ~~DDD~~ d3.

Thank you, Martin for being part of this process.

Like all things, this approach is open to ~~discussion~~ dialogue.

UPDATE

Brian has written an article called, It’s all about the dialogue. (digg.it)

Dialogue-Driven Development

Robby Russell — Wed, 02 Aug 2006 21:55:00 -0500

Just a few months ago, I wrote a short article called, The Art of Delivery, which outlined how we at PLANET ARGON approach iterative development and how it relates to quicker release cycles. I wanted to follow up with this and add some more thoughts to that and what we’ve been trying and learning since that point in time.

With iterative development cycles, we’re able to focus our attention on very specific and well-defined goals while we work with the client to organize the other goals that they’d like us to help develop solutions for.

An End to the Product Backlog

While everyone at PLANET ARGON has been doing some research on modern Agile-related methodologies, we’ve been throwing a lot of ideas back and forth… and often times we end up cherry-picking individual practices and throwing it into our evolving processes.

The problem that we’ve seen with most examples of using a standard Scrum Product Backlog is that it focuses too much on tasks rather than providing solutions for goals that are central to the success of the project. It also requires that someone maintain, on a regular basis, a well-defined list of tasks, which often times the client (Product Owner) dictates. We’ve seen many situations where a client has more feature requests than is necessary in order to attain the goal that was originally set. If we had a nickel for every time we heard someone say, “wouldn’t it be cool if it did this?”

I’ve personally worked on many projects that fell into this routine too early in the development cycle. Most clients that we work with are trying to provide a solution for their users and aren’t always the best Domain Expert. Taking the whole less is more approach, it’s vital that the earlier you can get your users in front of your application, the sooner you can get them to generate feedback, which aids in you making educated decisions about what to add to the project later on.

Features are Expensive

Aside from the monetary costs of adding new features and functionality, it is important to remember that as you add new code to an application you increase the maintainability and overall scope of the project. With each new feature, the requirements change, complexity increases, and as far as your users are concerned, they are now being exposed to something new, which may or may not be what they want or need. For example, I was in a sales meeting yesterday and our potential client mentioned that at a former job during the dot-com era, their web team added e-Cards to their web site and it had nothing to do with their business model. The users did however use this new feature but they later went out of business. Perhaps they should have been an e-Card business instead. Imagine if BaseCamp added a local weather feature… I might use it… but it doesn’t help me manage our projects any better.

When clients approach us with a new feature that wasn’t previously discussed, we have to ask them they Why, What, and How? What goal is this feature providing a solution for? Do we already have a solution implemented that solves this problem? Is this a new goal and how (and why) did this goal come about? What are the costs of implementing such a feature and how will it affect the current stability of the user base and application? If we put it off 3 months, would it cause the project to come to a grinding halt? What about 6 months?

It’s important to always remember that one of the biggest problems in software development is feature creep. Many projects fail due to this and as a project manager, developer, or client… please consider the consequences and benefits of each new feature. Focus on the goals and connect the dots from there.

Get the goals clearly defined and provide clear and simple solutions for them.

Just Say NO to Bloat!

Start with a Mission Statement

One of the new things that we’ve begun doing with a few new clients is assigning them with an initial task of providing us with a Mission Statement. From the Mission Statement we can ask how each goal that the client and we outline relates to it. If one of the key goals of the Mission Statement is, “to provide gorillas with easy access to basketballs”... we will have to question any goals that imply that we might also need to provide access to soccer balls, car batteries, or scissors… or that when a gorilla is getting their basketball we might want to provide them access to stock reports. We’re not trying to solve all the gorilla’s problems and it would be naive for us to think that we know what they want before we’ve had a chance to really engage in that dialogue.

Users are the Domain Experts

Very rarely do we get a chance to interact with users before we’ve begun coding a project and getting an alpha release in front of a subset of users. Brian and I just got back from a few days in Washington DC, where we worked with a new client. They have an existing GUI application that began development in the mid-90s and we’re being contracted to help build a new solution to the problem that they began to solve ten years ago. The application has suffered from a lot of feature creep as many evolving products do. As they gave us a demonstration of their existing product, we saw first hand how it was even difficult for them to remember why Feature X was in the system. “Most customers don’t use that anyways.”

So, why is it there? Of course, nobody remembers why everything is there now. As developers come and go projects get managed by various people over the course of their life, many of different opinions and features get injected into the application. It’s a common problem and it takes a lot for a company to finally admit that it’s time to throw it out the door and start fresh.

The old rules don’t apply anymore. *

One of the first things that we did in our meetings was discuss what goals their product was aiming to provide solutions for. What do they believe that their users want and need? To get this answer, we scheduled a few conference calls with real users of their existing software! I cannot describe how helpful those interviews were and we saw a lot of consistency in their goals as users of such a system. It became apparent that they were the Domain Experts and as we move forward with the project we are going to have access to interact with those users.

Rethinking the Dialogue

When thinking about delivery, we must consider the major obstacles to overcome during the course of an iteration or release cycle. More important than having well-defined deliverables is having well-defined expectations. If you’re delivering a prototype, be clear about what a prototype is and what is it not. Schedule regular meetings with your client throughout the process. Keep the client updated as much as possible. Ask questions as soon as you can… and be sure to ask them the right questions.

There is an art to it and it’s important that you keep this process lightweight and agile like you do your development process. Perhaps we need to think of development and project management under a new heading… *Dialogue-Driven Development? ~~DDD~~? ...just what we need… another acronym. ;-)

UPDATE

We’re not going to call it DDD… just d3.

Robby on Rails: Tag clients

Tip: Link to Unimplemented

Related Posts

Embracing Chaos, part 1

Rails Business: "Weekly" Review #3

Licensing and Client Agreements

Escrow

Project Planning tools

Ruby on Rails versus .NET

Three things Tim’s learned from Freelancing Rails

Client issue tracking and documentation

Join the Community

Rails Business: Weekly Review #2

Subcontracting

Change Requests

Dealing with large clients

Join the Community

Rails Business: Weekly Review #1

Health Coverage

Client Expenses

Hosting Client Repositories

Naming Your Business

Other Topics

Join the Community!

Embracing Failure, part 1

Those that Tend the Store need Dialogue

For starters, we’re misguided

Is there even a problem?

Take action!

Teams Need Healthy Collaboration

Project Enlightenment with d3

Matz on Considering Interface

The Technology of Dialogue

Question

Dialogue-Driven Development is about Listening

The Value in Face to Face

Two Ears, One Mouth

Information Anxiety and Solutions

Project Illuminatus, an introduction

Dialogue-Driven Development is about rounded corners

Related Articles

DDD (d3) is the new conversational software development

Dialogue-Driven Development

An End to the Product Backlog

Features are Expensive

Start with a Mission Statement

Users are the Domain Experts

Rethinking the Dialogue