Index Cards

Extreme Programming has this strong tradition of using index cards to track user stories, or to aid in design through the use of CRC cards.

Now, I have always had a strong preference for Excel spreadsheets.  You can print them, e-mail them, share them, and save them.

But there is something wonderful in the very nature of index cards.  Their very constraints create interesting feedback loops.  Think of all the objections that you might have against them:

Index cards are too easy to lose.

Yes – but why are you writing anything important on an index card in the first place?   At the end of the day, the only important work product is the code.  Requirements and any other models exist to facilitate conversations about the code.  If you have been writing tests along the way, when the coding is done, the requirements don’t need to exist anymore.  The requirements aren’t sacred.  The only thing that is sacred, the desires of your users, cannot be captured in any format, but must be discovered through a constant dialog.

Index cards are too bulky.

If you have more index cares than you can manage, then your user stories are either too fine grained or your scope is too ambitious.  Either way, the cards are telling you that you need to change.

This is a pet peeve of mine.  Quite often, when you are doing the wrong thing, it will be difficult.  The correct solution is not to make it easier to do the wrong thing, but to change what you were doing in the first place.  

Only one person can “own” an index card at a time.

So what?  Distributed ownership is the worst thing that can happen in project management.  If everyone owns a task, then no one is really responsible for carrying it out.  

Having said all that, I am still mulling over the use of index cards in my process, and have started collecting links about index cards in del.icio.us.

Holistic thinking is disruptive

In the November issue of the Atlantic Monthly, there was a brief article about the heuristics used by the US intelligence community to detect spies.

They may also take a "holistic view of world affairs" that could lead them to believe espionage is "morally justifiable."

You can read this any number of ways, and I won't debate the ethics of making decisions to support particular policies of this adminstration in spite of common sense (or holistic thinking) telling you otherwise.

But I would like to touch briefly on his this might affect your organization. When it exceeds a certain size, every organization begets a hierarchy of departments. While the organization, as a whole, might wish to move in one direction, each department has its own incentives, which sometimes contradict the organization's larger goals.

In such a world, to think holistically is to think about disruption, as any move to re-align the departments with the organization's goals will result in disruption to that department's practices.

Behavior Driven Development

I recently read an interesting paper by Dave Astels, entitled A New Look at Test-Driven Development, which suggested that Test Driven Design is overly focused on testing, which gets in the way of reaping the true benefits of TDD.

I agree that using the word “test” when describing TDD definitely gets in the way, when explaining it to other people.  Management asks, “Why are we hiring testers if developers will be writing tests?”  Developers ask, “Why should I write unit tests for code that will get tested by the (manual or automatic) acceptance tests?”  And so on.  You get the usual objections to TDD.

So I am down with giving TDD another name, but what threw me was the suggestion that we ought not to use the word “test” when actually writing the tests.

In Behavior Driven Development, tests are called “specifications.”  Fixtures are called “contexts.”  And instead of assert, one would say “should.”  (Dave’s essay has examples of their usage.)

Initially, I was fairly dismissive of what seemed like a cosmetic change, but I decided to give it a go for the past week.  Here is what I found.

I wrote more, smaller test fixtures.  Whereas I used to write test fixtures with names, like CustomerFixture, I found myself creating many little contexts, with names like CustomerWithOverdueBill or CustomerWithoutAddress.  

I wrote more asserts per test.  Each test started with a particular context, invoked a particular operation in that context, and then verified the expected resulting context.  That verification often took multiple asserts.

The tests naturally had better names.  In the past, when writing tests for a Customer class, I might have tests with names like testSetAddress.  Now, I find myself thinking in terms of scenarios, so that the CustomerWithoutAddress context might have a specification like settingAddressForFirstTimeSendsNotifcation.

In summary, this change in perspective has proven extremely useful, so I am sticking with it.