Robby on Rails

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?

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.”

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.

Related Articles

• 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

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)

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.