PragDave

Some Agile History

I spent this afternoon reorganizing (ok, just organizing) my files. In the process, I came across some of the notes I made in Snowbird back in 2001.

That was when 17 mawgs^[1] who cared about projects and software got together to discuss what were then called Lightweight Methodologies. XP had just taken off, and SCRUM was making waves, and we all wanted to see if there was enough common ground for us to isolate some underlying principles. In the end, I think we did something far more important—we isolated a set of four common values, and wrote them up as the Agile Manifesto.

As the conversation began to gel, I wrote down a short bullet list of things we were saying:

Soon after, we broke for lunch. Martin Fowler and I were standing at the whiteboard, trying to see if we could come up with a summary which captured the mood of the room. I noticed that as we were talking we often seemed to focus on what we didn't like as much as on the values we believed in, so we experimented with writing down our conversation that way: we prefer X over Y. Gradually folks drifted over from the lunch table and the conversation flowed. (The picture that Ward took that forms the background on the Agile Manifesto site shows the group clustered around the board). I think we sat down after lunch with five bullets on the board. By the end of the afternoon, it was down to four, plus an introduction. I copied the whiteboard into my notes too:

You can argue the implementation (I see some teams that use the word "agile" when they really mean "chaotic") , but the values still ring true to me today. I think the Agile Manifesto has helped teams around the world rethink their priorities, and in the process has helped re-humanize software development.

And that's as it should be.

---

^[1] Middle-aged white guys

Homophone joke

Zachary and Henry, my two boys, like to play the homophone game while waiting for our traditional Sunday breakfast at a local bagel store. Today, Zachary wanted to read his book instead, and came up with a neat way of telling Henry.

Henry: Want to play the homophone game?

Zachary: No.

Self-organizing Stores

I'm wondering: could the same organizing principles that work for community web sites work for retail stores?

If you go into a bookstore, you'll notice that not all books are displayed the same. Some are displayed on tables at the store entrance, or at the entrance to particular sections. Some are displayed on endcaps—that narrow space at the end of a shelf. And some are displayed on shelves with their covers facing the public. And then there's the vast majority of books, coyly showing you just their spines.

And then there's the shelving itself. Some books have clear homes: a book on the Java libraries likely belongs under Java programming. But where does a book on Ruby belong? Programming languages? Web development? Next to Perl and Python? The jewelry section?

Ever wonder what determines where a book goes and how it is displayed.

The basic answer is that most large bookstores ignore the publishers shelving suggestions and decide at head office where each book goes, often based on title alone. This is why you sometimes find a book a long way from where you'd logically expect it to be.

And when it comes to displaying a book more prominently than the standard shelving, there's another simple answer. Publishers pay for promotions, and stores display the books appropriately.

Are either of these practices in the interest of the customer? Perhaps indirectly—bookstores make a lot of money from the fees they charge for promoting books, and it could be argued that those fees keep the stores in business. But in terms of serving their primary purpose, which I'd define as making it easy for customers to find and buy interesting books, I'd say that both practices are suboptimal.

Having a central department decide shelving relies on one person being able to decide the likely audience for each book under their care, and then to decide where the average reader would expect to find that book. Both can at best cater to the typical case, and are bound to lead to frustration.

The reader is also poorly served when it comes to promotional placement. Sometimes it's useful: having a table by the front door piled with the latest Harry Potter is helpful, given that you know that a large number of people will flock in to pick one up. But for the less popular books the practice again moves decisions from the consumer to some central marketing department. Publisher Xyz may want the world to know about a new book, but the world might not be interested.

Online we address these kinds of problems using various self-organizing folksonomy systems: tagging, search, top-ten lists, "readers who bought X also bought Y" and so on.

So could we do the same in the retail world? I think it might be possible.

Say you had a store where you encouraged people to reshelve things. You'd have broad sections (Computers, Photography, and so one), and some cardboard labels you could put on the shelves themselves. People could write their own labels, create their own sections, and move books as they saw fit. If someone really likes a book, they could turn it face out to show others they approve. They could even move the books onto display tables. Not sure if a Photoshop title belongs in Photography or Computers? Put a copy in both sections.

Would such a store work, or would it just be chaos? I frankly don't know. But I suspect that people felt that user-organized sites such as wikis wouldn't work, and Wikipedia and friends have proven that wrong. Flickr and del.icio.us have shown that tagging is a great tool for organizing content. And all these sites have an additional, emergent, property that would be wonderful to see in a bricks and mortar store—they allow serendipitous discoveries. You come across things that delight you that you wouldn't have thought to look for.

Wouldn't that make it worth going to a real store again?

Cheese on Toast

DO NOT TRY THIS AT HOME

I love good cheese on toast. The trick is to get a nice, thin, lightly burned top while keeping the bulk of the cheese good and gooey. The skin gives it taste, the goop texture and follow through.

Tonight I saw a trailer for a cooking show where the chef caramelized the top of a creme brulée with a blowtorch. I couldn't resist.

Lightly toast some bread. Add a really, really thin spread of marmalade (optional, but try it...). Top with grated cheese and apply the MAPP torch. You'd be surprised just how close you have to hold it to get the cheese to brown—I started waving it vaguely in the direction of the bread, but ended up playing the flame directly over it.

The result was gorgeous.

DO NOT TRY THIS AT HOME.

Don't wear the yellow trunks

Over the last few years I've grown increasingly attached to the idea that progress is in the doing of things, and not in the things that get done. We learn, we grow, and we have fun as we change things, and not when we're created something static. I wrote a short piece called Artifacting a while back, and Andy and I followed up with an IEEE article.

Now ze frank has a wonderful video podcast talking (indirectly) about the same thing. The fun's in the surfing, not naming waves.

Think. Not just a sign on a desk...

...but a way of taming your desktop.

I have to 'fess up. My desktop discipline is appalling. I run two 23" monitors on my main machine (invaluable when laying out books). The trouble with that is that I tend to leave lots of applications visible at a time: NetNewsWire, Mail, iChat and so on all compete for my attention.

So I'm experimenting with Think, a free app for OS X with a simple mission—it hides everything but the application you're using. But, for me, the killer feature is that you can still pop up other application's windows, use them, and then use a simple key chord to hide them again. It seems trivial, but in the two days I've been sing it I've found it fits nicely into my workflow—I want to concentrate on one thing for a length of time, cutting out distractions, but at the same time I need to dip into ancilliary applications every now and then.

Two Hands Bad: The Frustrations of Dreyfus Level One

A while back an interviewer asked what I would do if I had three months of free time. Without hesitation I said "I'd take piano lessons." I've been hacking away on pianos since I was a kid, but I never really learned how to play anything real.

So my wife got wind of the interview (thanks, Google), and for my birthday I got piano lessons. In fact, I got perfect piano lessons—my piano teacher is totally flexible, into theory, and can play just about anything, in any style. He sets homework to do one thing, I get sidetracked and bring back something different, and he just rolls with it and I learn from what I did. It's invigorating, and great fun.

But I'm learning first hand about the Dreyfus model.

Installing Rails on OS X

There are two approaches to installing Rails on OS X. One is to use a package manager (typically MacPorts). The other is to do a traditional “install from source.”

There are two canonical descriptions of these routes. For the MacPorts version, folks turn to James Duncan Davidson's blog post.

For the do it yourself route, people favor Dan Benjamin's description. And the good news is that today Dan has released a totally updated guide to installing Ruby, Rails, Mongrel, and MySQL on OS X.

Which to use? The choice is yours. The MacPorts route is easier, handles dependencies automatically, and makes it a snap to update (but only after the MacPorts repository has itself been updated). The source route gives you more control over what is going on.