Bad Usability Calendar 2008

The 2008 edition of the Bad Usability Calendar is out and available for download. Go get it.

posted by randy on Monday, Jan 28, 2008

One who never rested

Ten years ago this month I returned from serving a full-time mission in Mexico. Just two months following my return I found myself again in Mexico, returning to the headquarters of my mission for a special conference at which Gordon B. Hinckley, president of The Church of Jesus Christ of Latter-day Saints, would be speaking, along with Elder L. Tom Perry.

In a bizarre turn of events, the night before he was to speak I was asked to translate from Spanish to English for both President Hinckley and Elder Perry as they sat and listened to the other native Spanish leaders scheduled to speak the following day. You can imagine I didn’t sleep much that night, pondering at length how I was ever going to translate for a man revered by many, myself included, as a prophet of God.

The following morning I sat on the stand about a dozen chairs down from where President Hinckley would be seated. As he entered the building I had the privilege of greeting him. I’ll never forget the look on his face as we shook hands. It was one of being physical exhausted, likely due in part to the fact that he was traveling to several locations throughout Mexico within just a few days, and definitely due in substantial part to being 87 years old.

Incredibly, this was ten years ago. I’m certain he was rarely less tired during those latter ten years than on the day I saw him. And yet he never rested, figuratively (and probably literally). I remain in awe of all that he accomplished, dedicating more temples than any other church president, among other very notable efforts.

As an aside, I totally botched the translation. I considered myself fairly fluent in Spanish at the time, but because we were in an enclosed, round, completely concrete stadium, the reverberation from the stadium speakers and my location on the stand made it nearly impossible to hear what was being said. Since that day ten years ago, I’ve long wished I could greet him anew for the chance to apologize for my deficiencies that day. However, being the incredible, humble man he was, I’m certain it was of little consequence to him. “Carry on, good brother” or something along those lines presumably would have been his reply.

We’ll miss you, President Hinckley.

posted by cameron on Monday, Jan 28, 2008

Requirements

Today I stumbled across Behavior-Driven Development-BDD for the first time. It’s an evolution of the thinking behind Test-Driven Development-TDD. The theory is intriguing. I like the focus on behaviors rather than tests. It appears to be more user experience and results oriented.

At its core are three principles which really ring true with me:

1. Business and Technology should refer to the same system in the same way
2. Any system should have an identified, verifiable value to the business
3. Up-front analysis, design and planning all have a diminishing return

But the reason I bring this up is because of the “story” model they present for stating requirements:

Model

As a Role
I want Feature
So that Benefit

Example

As a savings account holder
I want to transfer money from my savings account to my checking account
So that I can get cash easily from an ATM

Most requirements or feature requests only have the “what” portion of that statement. How cool would it be to keep the “who” and the “why” right next to the “what” of each requirement?

I don’t know if the cost/benefit is there for this approach. Again, I just read some articles today. It could take a lot of time to gather all of a project’s requirements this way. But there would definitely be some value. Think of the inevitable prioritization discussions. Which feature is most important? I’m certain that keeping the who and why as a part of those discussions would lead to better decisions.

I’m a big Ruby on Rails fan. Because of this BDD reading, I finally took a look at RSpec, a BDD framework for Ruby. I’m equally intrigued here and intend to try this out on my current project.

They expand on the “story” model adding scenarios.

Story: transfer from savings to checking account
  As a savings account holder
  I want to transfer money from my savings account to my checking account
  So that I can get cash easily from an ATM

  Scenario: savings account has sufficient funds
    Given my savings account balance is $100
    And my checking account balance is $10
    When I transfer $20 from savings to checking
    Then my savings account balance should be $80
    And my checking account balance should be $30

  Scenario: savings account has insufficient funds
    Given my savings account balance is $50
    And my checking account balance is $10
    When I transfer $60 from savings to checking
    Then my savings account balance should be $50
    And my checking account balance should be $10

RSpec then allows you to build this story and scenarios right into the actual code. The RSpec site has more on that.

Again, would it be valuable and useful to gather requirements like this prior to coding? We have to get at least some of this information before we can complete this feature. This just seems like an interesting way to document that information. For what its worth, it’s got me thinking new thoughts.

posted by tadd on Wednesday, Jan 23, 2008