Extreme Fiction?

Sometimes, just for the hell of it, I’ll think, “What if we approached (discipline X) the same way we approach (discipline Y)?” Mostly I do this because it’s amusing, but as a wannabe novelist, I can also make the excuse that it brings up some interesting story ideas.

One of these story ideas is, “What if people approached spellcasting the same way they approach computer programming?” I’ve got visions of mages hunched over their PDAs, writing spells test-first, searching for the latest open-source code on grimoire.google.com. It’s a fun contrast against the usual idea of spellcasters waving their hands and saying weird incantations.

A couple of nights ago, as I was drifting off to sleep, a new idea occurred to me: What if I approached writing the same way I approach programming?

Well, let’s see. Since I do Extreme Programming at work, then I guess I would be doing Extreme Fiction.

I would have a bunch of “story cards”, each representing some new customer value my book is supposed to deliver. Things like, “Hero gets the girl in the end”, or “The running-away scene isn’t believable enough — add an argument scene to set the stage”. I’ve actually used something a bit like this before: write each plot point on an index card. But in the Extreme Fiction world, each card would include a time estimate.

Of course this would be a team effort. Pair Writing would be mandatory for all production text. And there’d probably be a Fiction Manager, and of course the On-Site Customer.

The Customer, as in XP, would be someone to make business decisions: someone who knows what the market wants, can write the story cards for each new enhancement, and can decide, once the writers put their estimates on the cards, which ones are most important each week, and which aren’t worth the cost. Maybe this person would be an editor from the publishing house, or the person who makes the purchasing decisions for a bookstore or library. Or a big-name author (who’s proven they can come up with stuff that sells). Or maybe just a fan of the genre.

At each weekly Planning Game, the Customer would look at the time estimates made by the writers, and would decide which story cards are most important for that week’s iteration. And there would be the standard daily Stand-Up Meeting, where everyone on the team would say what they worked on yesterday, what they plan to work on today, and what obstacles they’re facing (“We’re having a hard time making the sex scene work, so if anyone has any ideas, see us after the meeting”).

The team would, of course, practice Shared Story Ownership: everyone owns the entire story. Two people at a keyboard are all-powerful: they can change anything in the story, as long as they both agree to the change. We might even have more than one novel going at the same time, so if I was sick of writing mysteries, I could hop over and work on the romance novel for an afternoon.

We would build each novel incrementally. Each time my pair and I picked a story card to work on, we would say, “What’s the simplest thing we could possibly write that would make this work?” We would start with a simple design, and only add complexity as it became necessary to make the story cards work. By adhering to YAGNI, and constantly keeping the plot “as simple as possible (given the story cards we’ve accepted so far), but no simpler”, we would make it possible to work at a predictable pace.

And we would focus on keeping the novel in a constantly shippable state: trying never to end an iteration with plot threads dangling, or incomplete scenes. Even the first iteration would turn out a complete (if short, and possibly boring) story.

The more I think about this, the more I think it might actually work. (That probably means I need more sleep.)

The hard part would be writing automated tests to run against the plot, so we could refactor with confidence…

XP: Fail first

We’ve been doing Extreme Programming for almost five months now, and brought in some pretty sharp XP geeks several times. I’ve been learning a lot along the way, and I haven’t been sharing very much of it. (Bad geek! No M&Ms!)

So I decided I’d start writing about some of the things I’ve learned along the way, and more than that, how I learned them. Abstract principles are great, but anecdotes are a lot easier to learn from.

I’ll start with something I actually learned a couple of years ago, long before we started doing XP: Make your tests fail first.

XP teaches that you should write your tests first, and then write the code that will make them pass. An important detail of this, which people sometimes gloss over when talking about it, is this: once you’ve written your test, but before you’ve written the actual code, you should run your test and make sure it fails.

I learned this by not doing it. I was writing a test to make sure that a particular method threw an exception if you passed it an invalid input. The code looked something vaguely like this:

procedure TestMyWidget.TestValidatesInputs;
    Fail('Expected an exception');
    { do nothing -- test passes if we get an exception }

(I don’t think it was checking for nil; it was something a little subtler than that, but I don’t remember the details now.)

I wrote the test, wrote the validation code that would make it pass, ran the tests, got a green bar. All was well, right?

Well, no. All was not well, as I discovered a few days later, after a tedious debugging session. Because, in fact, my validation code wasn’t validating correctly. It wasn’t throwing an exception when it should have. And my test didn’t catch it. Why?

Because I expected the Fail method to make my test fail, somehow, mystically, magically. I didn’t understand how it worked. I thought it set a flag somewhere, and if the test finished and that flag was set, then the test failed. Right?

Nope. The Fail method works by throwing an exception. Which my “except” clause promptly swallowed. The test, as I originally wrote it, would pass under two different conditions:

  1. if TMyWidget.Create threw an exception, OR
  2. if TMyWidget.Create did not throw an exception, and the test called Fail.

Yeah. The test would never fail.

Lesson learned: It’s not enough to make sure your tests pass when you expect them to. You also have to make sure they fail when you expect them to, because that tests your tests. If a test doesn’t fail when you expect it to, then it’s probably not testing what you think it’s testing.

That’s why you expect failure points along the way:

  1. Write a test for a method that doesn’t exist yet.
  2. Try to compile. The compile should fail, because the method doesn’t exist yet. This is failure #1. If you expected to get failure #1, and you didn’t, stop and find out why.
  3. Write the method, just to make the compiler happy, but don’t implement it yet. Put an empty method body, return a bogus result, whatever.
  4. Run your test. The test should fail, because you haven’t written the code to make it pass yet. This is failure #2. If you expected to get failure #2, and you didn’t, stop and find out why.
  5. Then, and only then, write the code to make the test pass.

There will be times when you don’t expect failure #1, because you’re testing a new feature of an existing method. There will even be times when you don’t expect failure #2, because you’re just adding a few extra tests as a safety net for code that’s already working. Both of these are fine, and have their place.

But most of the time, you’ll at least expect failure #2. And you should see to it that you get that failure.

The correct version of the above code, by the way, would be this:

procedure TestMyWidget.TestValidatesInputs;
    Fail('Expected an exception');
    on EInvalidOperation do
      { do nothing -- test passes if we get an EInvalidOperation }

This test fails when it’s supposed to. It also documents (and tests) the expected behavior of the code: it should throw an EInvalidOperation, and not, for example, an EAccessViolation. Better for the human reader, and better for the test.

XP and deadlines

I went to visit my family this weekend. Before I left the office, I grabbed an XP book to take along and read. I happened to pick “Extreme Programming Explained: Embrace Change (2nd Edition)” by Kent Beck and Cynthia Andres.

I only managed to read the first chapter over the weekend, and even that had some real eye-openers. In particular, it had things to say about the looming deadline we’re facing at work.

If I do my very best writing a program and people don’t like it, I can still feel justly good about myself. … If how I feel is based on an accurate read on whether I did my best, I can feel good about myself by doing my best.

When self-worth is not tied to the project, we are free to do our best work in any circumstance. In XP you don’t prepare for failure.

You may have enough time, money, or skills on your team or you may not; but it is always best to act as if there is going to be enough. … I often ask developers in a dilemma, “How would you do it if you had enough time?” You can do your best work even when there are constraints. Fussing about the constraints distracts you from your goals. Your clear self does the best work no matter what the constraints are.

I read those passages to Jennie last night, and she nodded and said, “That makes sense.” I find it amusing that she, as a non-programmer, found these easier to accept than I did.

We’re under a deadline, and we have to keep that deadline in the forefront of our minds as we work, right? Well… hmm. Maybe not. Maybe we can do better work if we just think about the work, and about doing the best job we can, and asking ourselves, “How would we do it if we had enough time?”

We’ve been doing XP since February, not as a totally religious thing (we still don’t do 100% of our development test-first), but well enough that we’ve got a plan laid out from here until the release date: which story cards we’ll get done in which iterations. If we can keep our velocity up (and avoid introducing too many bugs), then we will hit our ship date, so even though we’ve been worrying about it a lot, we don’t need to. Our challenge as developers is not to worry about the deadline, it’s just to keep plugging away and getting things done.

When I read Beck’s first chapter, my gut reaction was, “We can’t do that; we’re under a deadline!” But the more I think about it, the more I think he’s right. The owner of our company has said more than once, “I don’t want to hear anybody saying, ‘That’s not my job'”, but here it’s true and for good reason: It’s not my job to worry about the deadline; our internal customer is already taking care of deadline planning and can do it far better than I can. It’s my job to write the best code I can.

If we don’t spend effort worrying about the deadline, we may be able to do better work in less time. If we focus on doing the best work we can do, we can keep our excitement level high, keep from getting burned out, and keep the good code coming.