def euler(x); cos(x) + i*sin(x); end

If you’ve paid any attention to our discussion of d3, you’ve noticed that we’re just beginning. We’re trying to articulate the principles that we believe define an effective approach to “client” interaction. I say “client” because it’s not necessarily true that the people are clients in the traditional sense. Organizations often address that with a term like “internal client” to refer to another department, for instance. But that’s a different topic.

In the #d3 channel on irc.freenode.net the other day, Brasten posted this:

17:23   brasten >> anecdote--
17:24   brasten >> spend 30 minutes on the phone with a client discussing a project...  going over all the features he 
                   wanted.
17:25   brasten >> weird stuff.... needed to send small emails with outlook-compatible attachments... import CVS 
                   documents, yadda yadda... none of it made any sense...
17:25   brasten >> finally I asked, "what exactly is the PROBLEM you're having that this project needs to address??" 
17:26   brasten >> the guy literally sighed.. paused... and said, "I just want to be able to run my business from my 
                   BlackBerry."     ahhh.... now that's a very different project....we can solve that.
17:26   brasten >> and we were the first developers to actually ask him that.
17:27   tacodog >> hah
17:27   brasten >> -- end anecdote.

You may have had this same experience numerous times. It happens frequently enough to make us ask, “what’s the dynamic here?”

I think this exchange illustrates one of the core principles we’re after: we prefer problem statements because they will always be simpler than a solution or implementation. The problem statement is at a different level of abstraction. It is easier to understand, and thus easier to talk about. The problem statement is as close as we can get to the core. Every possible solution or implementation will be layered around this.

Simplicity is an interesting concept. My dashboard dictionary has this as one definition:

the quality or condition of being easy to understand or do.

We often refer to implementations in terms of simplicity, or simple versus complicated. It’s hard to imagine a compelling argument for something being more complicated than it needs to be. In general, we tend to equate “simpler” with “better”.

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.

I’ll admit, I feel silly sometimes trying to describe these ideas. They seem really basic. But if this whole dialogue thing were that simple (pun intended), we would rarely, rather than frequently, have exchanges like that above. So, drop by #d3 and help us figure out how to make it as simple as it should be, but no simpler.

I typically conduct all of my personal business online: mortgage, credit card bills, utility bills, cell phone bill, etc. It’s a great convenience. That’s probably the primary reason. It’s simply more convenient than anything else. I can’t think of any other reason I do it. If there were some attendant in a window I frequently walked by, I’d just as soon give the person a check or credit card to pay a bill. With no waiting line, it would take about the same amount of time.

But since online is the most convenient, I usually use it. Now, since paying these bills means I’m parting with hard-earned money, I tend to be pretty critical of the process. Add to that the fact that these folks, bankers, etc. generally have a ton of money, I expect them to present a pretty nice experience when separating me and my cash. If not nice exactly, it should work well.

So after an experience with Chase’s credit card site, I decided to send them a little note of helpful criticism. I will say, that Chase’s newly redesigned site is probably the best of the 8 or so I frequently use. Even so, I don’t understand how stuff like this gets into the website. Maybe I just have too high of expectations.

Hi,

I just went in to update my business phone number today and was required to fill out every piece of information about my address and personal phone number. That is plainly stupid. I wanted to change one small bit of info and I had to retype everything. There was not even a way to load the existing values into the form.

Please consider your user when designing these forms. Making me enter all that information again when I did not want to change it was both a waste of my time and created the potential for me to accidentally enter incorrect information.

Overall, your site redesign is quite nice and I enjoy using this website much more than the last one. However, things like this form are awfully annoying when forced to deal with them. It creates the tendency to not want to update information because of the hassle. That’s surely not the result you’re aiming at.

Hope you can get these things straighted out. Just because they may be rarely used parts of the website doesn’t mean they should not get the same level of intelligent design. And if the folks who are designing the website don’t understand these issues, that’s a big problem.

Cheers,
Brian

So, do you think I’m expecting too much? What are your favorite examples of websites that should be a cut above, but often fall flat on their faces?

After you begin practicing TDD, or better BDD, for even a short while, it clicks. Once you get in the habit of thinking about the behavior you expect and describing that first in a test or spec, you realize there is a qualitative difference in how you are writing code. It’s not simply that you are writing code faster, or writing better code. You are working differently. A quantum leap, if you will. It’s a great, “Ah, hah!” experience.

I sketched a couple diagrams to try to describe this difference while chatting with Robby about creating shared meaning with clients. Check them out below.

Figure 1. Traditional linear perspective

Figure 2. Circular BDD perspective

The, seemingly, traditional view is linear. You start with no feature, do a bunch of whatever, and at the end you have the feature completed. The TDD/BDD view is quite different. Following the mantra—red, green, refactor—you start with a description of your expectations, you generate code that meets those expectations, and then you refactor. For all but the simplest bits of code, you will likely refactor numerous times. Refactoring is an explicit, purposeful, integral, regular part of creating code. And it’s not, typically, something you do to fix errors, which is how someone with a traditional view tends to understand refactoring. You refactor when your code is meeting your expectations (tests, specs) and those ensure that the product of your refactoring continues to meet your expectations. You refactor because the process of writing code changes how you are thinking about and understanding the code you write.

It’s difficult to find an analogue to this process in our everyday world. In construction, we would surely not build a room and then tear it down to rebuild it because our understanding changed. But an architect may well do that many times with a model in the attempt to create a solution that works. There’s no accurate, faithful way to transfer the architecture paradigm to software development. Many have tried, failed, and many will try again. Instead, BDD is an essential part of the software development paradigm and it’s processes should be understood, to some degree, by everyone participating in software development, clients included.

One significant challenge that we encounter is communicating the importance or value of a particular recommendation. There is more than conveying the information. We have experienced explaining to a client why it was necessary to refactor a particularly important part of an application. (In this case, it was more of a redesign, but since the behavior of the application was not intended to changed, we viewed it as a large scale refactoring.) The client acknowledged that our recommendation had technical merit, in some sense, but continued to view it as something of a diversion with little practical value. After all, the “features” were in place. We weren’t asserting that we would significantly change anything that the user interacted with. And the client was feeling the crunch of getting new features in front of the users.

So, the problem is much more than communicating information between developers and clients. It is essential to dialogue in a way that shared meaning evolves. The shared meaning brings our values into alignment. Then a true, rewarding process of collaboration powers the endeavor.

And now for a public service announcement…

Over the past month I’ve made a lot of changes to my VPS. Plug for Quantact, they’ve been great. Actually, I almost never talk to them. Which is just the way I like it; means everything is running fine.

So, a few highlights if you’re interested:

• Debian 3.1 to Ubuntu 6.06 Dapper Drake.
• lighttpd+fcgi to lighttpd+mod_proxy
• lighttpd+mod_proxy to nginx
• Typo to Mephisto

You probably haven’t noticed much but the last one. Hopefully I didn’t put any wrinkles in your day. I’ve been using Feedburner almost since the beginning of this blog. That feed has been updated and I believe is working. I’ve set up a route for the old Typo-style URLs so your links should not break. I’ll be getting tag based feeds going as soon as I can. And I’ll lovingly replace this awful default Mephisto theme. Justin Palmer is awesome, but I think he stubbed his big toe with this one. (Oops, the Hemingway theme is by Kyle Neath. Sorry Justin.)

I’ll post soon about setting up Mephisto in svk and svn, thanks to inspiration from Octoblog. Actually, double thanks, since Octopod inspired me to set up my VPS in the beginning.