UX designers need to learn more about agile development, and vice versa

April 7th, 2010

I’ve been reading a lot about UX design and user research lately (trying to hold up my personal end of the bargain I’m about to propose). Reading what some (emphasis on some) designers write about agile, it strikes me that they seem to see agile as this weird way developers insist on working that designers must accommodate so they aren’t ignored.

First, I feel sad that designers fear being ignored, feeling that their work or expertise is not appreciated. Second, I think designers need to do the work and research to understand agile better, so that they better understand its perspective and the benefits it can provide. Conversely, I think developers need to learn about UX design and user research, for the same reason. Otherwise it seems to me that even if you get both groups into the same room (or on the same team) to learn how to work together and to love each other better, they won’t have enough shared understanding to make real progress.

Turns out, cucumber/webrat is worse

March 16th, 2010

At CDD we use a fairly strange stack to run our automated in-browser (Selenium RC) integration tests.

When we started writing these tests back in 2007, we used the best technology we knew of that was then available, a Rails plugin called funkytown, since-abandoned brainchild of Pivotal Labs. Funkytown’s code is a little weird, and we’ve had to fix bugs and inflexibilities from time to time. We monkeypatched its rake tasks. Over the years we updated the bundled version of the selenium RC jar file several times.

We wrote another library (selenium-spec, which we open sourced once a while back) on top of funkytown that integrated selenium tests into rspec, provided the ability to chain examples (see this blog post), as well as some webrat-like helper methods, except better, enabling code like element('results').should be_visible.

So that’s what we’ve been using for a few years now. It’s not pretty, but it works. When cucumber and webrat came out, all the buzz made me think that we’d inevitably switch over some day in the beautiful future when everything will be perfect. However, I recently had the opportunity to try them out on a another pet project of mine, and I was surprised to learn that even though they have a much bigger install base than our install base of one, our crazy stack turns out to be better.

There are three major problems with cucumber/webrat/selenium RC, as far as I can tell:

  1. You can’t really use fixtures.
  2. Debugger breakpoints in your application code don’t work.
  3. I swear there was a number three.

All of those (well, at least the first two) aren’t true of our crazy stack, and I wouldn’t want to give them up.

There are some nice things about cucumber/webrat. The annotations are neat, and it’s kind of cool that you can run your tests as both Rails integration and selenium RC tests (although I imagine once your tests get realistically complex at all that is no longer so assured).

Perhaps a good opportunity, one day in that beautiful future, for us to clean up our stack, rebase it on some more modern infrastructure (or rewrite our own), and open source what for us has been a really useful tool.

Agile/UX Retreat

February 3rd, 2010

Last weekend I attended an interesting “retreat”, really a mini conference run in the unconference style. The topic of the retreat was “Agile/UX”, where UX = User Experience design. The motivating idea was that while the agile and UX movements have made important discoveries in their respective fields (software development and design, respectively) and really changed how people work for the better, both would be better together.

No agile methodology I know explicitly discusses how user experience design activities fit into the workflow. In the agile context, design usually means the design of code, not the design of the user experience. The standard response of agile to this accusation is “of course each project involves other roles, and they will just fit in wherever makes sense that fits with the principles and practices of the team”. While this may be true, by leaving design out of the explicit picture, many agile software development teams who are doing lots of other things right continue to ignore the importance of incorporating iterative UX design into their process, and therefore are delivering software efficiently that is not as effective as it could be.

I assume something similar is wrong with standard UX practice. For one, it seems that perhaps the design community still tends to think of design as something only done Big and Upfront at the beginning of a project, missing an opportunity to learn from their mistakes and iteratively improve their design as implemented in the hands of real users.

Based on my personal experience, this seemed like a great idea, so I was really looking forward to attending the retreat. At CDD we do work with designers, and although (if I may be so bold) we’re doing better than most informatics companies in this regard, it’s still clear to me that we could do even better. Thus far we’ve have a hard time testing/validating and iterating on user designs and working these activities into our software development workflow.

The retreat was inspiring and motivation building, having so many people in one room who care passionately about making great software from both design and development. One enduring theme was the abolition of “Us and Them” thinking. Two points are important here. One, we should think of designers and developers primarily as people, rather than as roles, people who work together and bring their competencies to bear on a common goal. Two, a given set of competencies that normally would be thought of as belonging to two separate roles can be found in the same person, so we should never be limited by thinking that a given person is either a designer or a developer, isolating them accordingly from activities that involve the other discipline. Design and development must work together, even within the same brain.

I would have liked more detailed discussion at the retreat, however this was difficult to accomplish in two short days. I also would have liked more representatives of the “business” or “money” role, because I think the same principle applies: abolish us vs. them thinking, and find ways for enlightened practitioners from a mix of all of these roles to combine their expertise effectively.

Further activity is planned, targeting something concrete to be presented at the Agile 2010 conference. Stay tuned.

Problems with apt, python2.5 and Ubuntu Hardy?

July 29th, 2009

I couldn’t find a good solution to this on the Web, so I’m providing one in case it helps anyone else.

I recently had a weird problem applying updates to Ubuntu Hardy, due to a failure while dpkg was configuring python2.5, giving me error messages like:

dpkg: error processing python2.5 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python2.5-minimal
 python2.5

I fixed this by allowing the pycentral rtinstall command to overwrite “local” files (which weren’t actually local, I think they were left over from previous versions of Ubuntu–I have upgraded the OS several times). In /etc/python/debian_config, I added:

overwrite-local = True

“aptitude safe-upgrade” then ran without a hitch.

Pair programming and microarrays

July 9th, 2008

Yesterday I met with folks at Lawrence Berkeley labs. The PI entered the room, full of energy and clearly ducking briefly out of the fray to speak with us. Part of the discussion revolved around microarray experiments. We’ve all heard about how notoriously difficult it is to reproduce microarray experiments. People have proposed minimum information standards (really they’re guidelines) to combat this problem, and we’ve also all heard that often these standards aren’t enough. Even if people are following the guidelines, inevitably a crucial piece of information isn’t obviously critical and therefore isn’t communicated.

The PI noted that he has seen it to be helpful when more than one lab conducts an experiment, so that each can help the other avoid finicky and/or tacit experimental conditions that would prevent others from reproducing their results. I have wondered for some time (and for the case of microarrays in particular) whether the practice of “pair programming” that we use in software development would be more helpful than minimum information standards to increase the reproducibility of complex experiments. The problem with this, as the PI pointed out, is that duplicating every experiment can get expensive, and in the world of soft money (especially today’s world), people are always looking for ways to make the research dollar go farther. The possible long term efficiency of duplicating some efforts to increase data value and reduce a tendency to go down blind alleys might not be easy to quantify, and thus not easy to weigh quantitatively against the immediate penalty of “getting half as much work done”. (That’s certainly true in software.)

The PI pointed out that even if direct duplication was too expensive, he still advocated some kind of collaboration on experiments. In particular he advocated getting people together in the same room to look at the experiment together as it was being performed, so that the collaborator might catch important things that weren’t immediately apparent to the person performing the experiment. This, at most, only costs a small amount of travel funds.

I asked the PI if others shared his views, and he said that most of the larger microarray efforts had some sort of distributed work going on, but he wasn’t sure that this idea had been formalized anywhere.

I’m interested in this not only because of its parallel with software work, but also because I work for a company focused on facilitating collaborative science. I’m very interested in the different forms that scientific collaboration can take, and how best to help them along.