The intersection of development and UI is an area I've got some interest in. Arena just shared this amazing article about a team's experience merging Agile project management with User Research and testing.

User Research as a Commodity (part 3 of 7) by Tim Kieschnick

Here (below the fold) are some of the things in the article I found eye-opening.

Sayings I use, only some of which are actually originally attributable to me. Anyone with research on a saying's provenance, feel free to comment. This page, unlike a normal blog entry, will be updated as needed with stuff I find myself saying with air quotes.

A comment is a lie waiting to happen.

"Legacy" means any program that people are actually using.

(Feathers: "Legacy" means "no tests.")

If you try hard enough, you can make anything fail.

There's no such thing as human error. (Only system error.)

If you pay attention to something, it gets better.

It's always a people problem. (Jerry Weinberg)

You can see a lot by looking. (Yogi Berra)

Yogi wrote a book called "You Can Observe A Lot By Watching" but I prefer to think he was misquoting himself.

Language Log has a take on this quote: She was seeing at me

Object-Oriented Programming is like teenage sex: everyone says they're doing it; few actually are; and those who are rarely know what they're doing. (Anonymous, via Misko)

Here's a simple test for whether you're doing it right: Is your data in the same class as the methods accessing it? Oh, really? Check again.

Double negatives are not unconfusing.

Encapsulation means putting similar things together, and keeping dissimilar things apart.

Of course, the trick of design is knowing along what axes to group or differentiate items. One rule of thumb that has served me well since the days of Gamelan -- when we were sorting dozens of incoming applets per day into categories -- is:

Don't look at the item and think, "What category does this item belong in? Look at the category and think, "If I were looking for items in this category, would I want to find this item?"

In other words, make your API fit the mindset of the user, not that of the provider.

Conway's Law: "Any piece of software reflects the organizational structure that produced it."

Or, "The structure of the code reflects the structure of the coders."

Read the error message.

Good Scrum diagram. Suitable for XP too (replace "sprint" with "iteration" and "daily scrum" with "daily standup").

Courtesy of Mountain Goat Software

Courtesy of Steve C and Alex Tabarrok

There is no "W" in "team"

Writing and Testing JavaScript-Heavy Web 2.0 Apps with JSUnit

Alex Chaffee & Edward Hieatt (presented by Alex Chaffee and Brian Takita)

JsUnit

Edward Hieatt (presented by Alex Chaffee)

CI for the Web 2.0 Guy or Gal

Chad Woolley

Full-stack web app testing with Selenium and Rails

Alex Chaffee and Brian Takita

Here's an RSpec trick I discovered yesterday. Sometimes when you're writing a test you want to loop over some precondition data. But if you do a loop inside your test (or spec), then all the cases will be subsumed in a single test method (or "it" block). This means you'll have the following problems:

• The first case to fail will cause the rest of the cases not to run. It'd be nice to see them all in a single test run.
• You won't take advantage of RSpec's cool self-documenting trick of labeling each it block with a full description of the failure, and it'll be harder to debug which case failed.
• If you're calling into Rails (e.g. in a View spec), you'll only be able to call certain methods -- especially render -- once per test method. That means that you simply can't use a loop inside a method to collapse redundant tests into a single block.

Ruby to the rescue! Instead of looping inside your it block, loop outside your it block.

1. Introductions. Anybody new? Any guests in the room?
2. Help! Anybody need assistance?
3. Neat! Interesting things we want to share.
4. Status. Only if there's time -- project or individual reports.

(Based on Standup 2.0.)

Brian Takita and Alex Chaffee gave a presentation at the SDForum Silicon Valley Ruby Conference over the weekend, entitled Full-stack web app testing with Selenium and Rails. We're going to do it again at Agile 2007 (and we'll have an extra half-hour next time, so we'll have time to do some interactive pairing with some hapless audience member).

Here are the slides, courtesy of SlideShare:

| View | Upload your own

I just gave a talk at the Web 2.0 Expo with Leslie Chicoine of Satisfaction. We shared our insights into the challenge of integrating foundational design methods (interaction design, usability design, interface design, interaction design) into a team doing Agile development (rapid releases, week-long iterations, high feedback and communication). It was a lot of fun! The room was packed, the energy was high, and they laughed at our jokes!

Here are the slides:

You can also see the slides here at SlideShare. Let me know what you think!

Mark and I were just waxing poetic about how great it is to delete code, especially code you just wrote. We pity the attitude of people who think deleting code is somehow wrong -- they feel so guilty that they won't even delete it right off, they just comment it out, and then check it in... We came up with the following simile:

Writing code is circling your way around a solution, like a dog on the hunt. When you're done, the final solution is going to be a lot smaller than your original perimeter.

This reminds me (Alex) of my favorite quote about writing: "Murder your darlings," said by Sir Arthur Quiller-Couch... or was it..?