Wed, 19 Apr 2006
An interesting story about pairing with users to implement new stories. I found it intriguing because it repeats some of my hobbyhorses from a different perspective (that of an APL programmer). Notice that he gives up on English in favor of examples. Notice also the adaptation of a programming language into a more-ubiquitous cross-domain language. (This made easier by the close fit APL starts out with.)
The part of the story about moving processing in from a distant site reminds me of what I've started calling a service-oriented development strategy. The idea is to forget about the program as an object but rather think of the project team as providing a repetitive service to the user base. In the company described in the link, someone—probably the product director—would funnel claims to process into the team. One person on the team would be an expert in manually processing claims. She'd be a bottleneck, so she'd enlist other available people—the programmers—to handle the simpler claims. Programmers being lazy, they'd quickly write code to make repetitive parts of the task go away. They'd also (and thereby) learn the domain. As they did, they could handle more complex claims, which would lead to more capable code. Lather, rinse, repeat.
Now, the truly lazy service person won't want to even type information into the program; she'll want the users to do it themselves. That means seducing the users into trading the ease of just forwarding a claim to the team for the benefit of higher throughput. So now—and only now—the programmers have to focus on making the UI usable by normal humans. First, they'll make it good enough for those few technology enthusiasts among the users. Then they'll improve it enough for the pragmatists and even the conservatives. (Thus, the standard high-tech adoption lifecycle is followed within a single project.)
At some point, you run out of claims that the product director thinks should be automated. So you stop and send the programmers off to do something else.
I've not convinced anyone to actually try this. I probably never will.
(Note: This strategy doesn't really match the story, since the users do nothing but claims processing. It's probably better suited to situations where the software is a necessary but non-central part of the job.)
One immediate objection is that this will lead to a lousy, patched-on-after-the-fact UI. For what it's worth, Jeff Patton (Mr. Agile Usability) doesn't think that's necessarily so. In fact, when I talked to him about it, he said that committing to a UI too early can hamper the project if there's not been time yet to incrementally make a decent model of the users' world(s).
Mon, 12 Dec 2005
What makes a design intuitive? is nice and readable short article about the two ways to make an interface that people will call intuitive.
Designing embraceable change is a follow-on that talks about how to introduce a new UI to an existing community. This has relevance to Agile projects that are continually tinkering with the UI.
The series ends with The quiet death of the major relaunch. Here's a trivial example of the approach:
The key point in this last article is this:
Our findings show that consistency in the design plays second fiddle to completing the task. When users are complaining about the consistency of a site, we've found that it is often because they are having trouble completing their tasks.
Thu, 21 Oct 2004
One of the things she talked about was a model of communication that she uses. It's summarized by the four questions in this posting's title. At a recent meeting, I compared something I'd just heard to those four questions and was inspired to do something I haven't done in many years: get so uncomfortable speaking to a group that I had trouble finishing.
Believe it or not, that's a recommendation. I have a fear of spending so much time in my comfort zone that I turn into one of those dinosaur consultants I scorned when I was young and fiesty. (Still do, actually.) I get uncomfortable whenever I notice I've been comfortable for a while.
Mon, 22 Mar 2004
A blizzard of ideas this time, all suggestive, none that I've been able to comment on sensibly.
Wed, 17 Mar 2004
"Agile" is not test-driven development, continuous integration, simple design, whatever; it's any feature, any order, most valuable feature first.
Part of the purpose of the workshop that led to the Agile Manifesto was to find a replacement for the term "lightweight processes." People felt that saying "I'm a Lightweight!" somehow didn't get the right message across to Gold Owners.
"Agile" was certainly a success in those terms. Jason suggests it might have been too successful now that everyone's piling on.
Perhaps, though I do think there are other unfortunate terms to go after first.
However, Jason's definition doesn't capture two of the values the Manifesto documents:
Jeffrey Fredrick on confidence due to tests.
And related: Alberto Savoia with some history of a testing tool company that's eaten its own dogfood. (Disclosure: I've done consulting for Agitar.) I was particularly interested in the effects of their dashboard, both good and bad. I remain wary of numbers. My normal preference is for dashboards and Big Visible Charts that are perceptual, fuzz out the precision in the data, and present the results of exploratory data analysis. But lots of numbers make it harder to game the system (consciously or unknowingly), and using the numbers in a system filled with human feedback ought to make them self-correcting.
Sat, 21 Feb 2004
Actually, this posting has nothing to do with that, but think about it. Why contend with adult immune systems when you can use immature ones? I imagine two viruses brainstorming a billion years ago, when one of them says, "Sexual reproduction!" And the other says, "Yes! And while we replicate within the hosts that have incompetent immune systems, the other hosts will nurture the cells we're using! Boris, you are brilliant!"
That interlude brought to you by Sophie "Why?" Marick. And, soon, no doubt, her brother.
P.S. The disciplinary agency piece is coming along, but the walking-through-refactoring example is 17 pages of test tables and code and pictures and text. This seems a problem.
Mon, 24 Mar 2003
there is one particular aspect of practicing "art" which seems conspicuously missing from the every day work of the programmer. As a musician, I might spend a significant portion of my practice schedule playing things that nobody would want to listen to. This might include scales, arpeggios, extended tones (good for improving control on wind instruments, for example), and various technical patterns.
This idea of practice has been a theme of Dick Gabriel's in recent years. Here's an abstract for a talk he gave at XP/Agile Universe 2001. The talk was titled "Triggers & Practice: How Extremes in Writing Relate to Creativity and Learning".
The thrust of the talk is that it is possible to teach creative activities through an MFA process and to get better by practicing, but computer science and software engineering education on one hand and software practices on the other do not begin to match up to the discipline the arts demonstrate. Get to work.
A final link: at an OOPSLA workshop on constructing software to outlive its creators, PragDave brought up the idea that we should be more ready to throw out our work and rewrite it. That ties in to a story Dick tells of the poet John Dickey. Here it is, from Dick's book Writers' Workshops and the Work of Making Things:
Dicky had numerous methods of revision. His favorite was redrafting, in which he would create new drafts of a poem until there were literally hundreds from which he could choose... Dicky viewed his process as one of experimentation. In the end, when he had hundreds of versions and drafts of a piece, he was able to choose from them. Surely some of them were better than others, and if he chose one of those, he was better off than he could have been.
PragDave inspired me to start throwing out and rewriting code, but I've done little of it yet. Unlike Dickey, I keep tweaking and tweaking and tweaking the same piece. There's never enough time to do it over, but there's always enough time to do it right...
Reading Dave's piece, I realized part of the reason I like verbs. We think of actual things in the world - rocks, trees, etc. - as standing alone. They are what they are, independent of things around them. That property we see in concrete objects is carried along into language, where we apply it to very abstract nouns like "requirements" and "quality". Those are not actual things, and they do not stand alone in any meaningful sense, but the conventions of language let us treat them as if they were and did.
In contrast, verbs customarily don't stand alone. In sentences, they take subjects and objects. Contrast two conversations.
Now, in the second conversation, Betty could have skipped the followup question. And, in the first, Betty could have said, "What does it mean to work on 'quality'?" My point, though, is that verbs pull you to ask the next question, to look for subjects and objects and connections, whereas nouns make it perfectly easy to stop asking. Since one of our problems is that we stop conversations too soon (including our interior conversations), consciously using a lot of verbs helps us.
But now I must head back to the taxes... Why is it that a crash in a tax program is so much more disturbing than a crash in the operating system?