The Extreme Programming Way To Handle User Anti Stories

Q: How can you handle a story that says a system won't have something, like security holes or user traps?

A: Write 'em on cards. Assign business value H, M, L. Optionally assess Risk. Estimate time to implement. If time to implement is larger than three weeks split the UserAntiStory and repeat.

I think you hammered that screw home pretty well -- DickBotting

Sarcasm noted. But why do we need anything more?

Hey, I like hammering screws home! It works great! I thought the sarcasm was subservient to the general recognition that screws hammer nicely! --AlistairCockburn

Q: XP doesn't seem well suited to projects which have strict security requirements. How do the security requirements affect the development process? Is there an ExtremeProgrammingChallenge which discusses this topic?

You can't handle security just through UserStories, or UserAntiStories, because SecurityIsHard. You might hire a security expert to tell you the ten most important things you need to do about security. These, then, could be stories and they get implemented in whatever order the customer dictates. But this is only a partial solution. You're still going to need security reviews before release. -- JohnBrewer

The problem is that, while the requirement may be easy to state (you need more than three sentences at a time scribbled on a napkin to understand the requirements), the assumption of UserStories in general seems to be that each can correspond to a specific engineering task. But UserAntiStories don't fit this model. Instead, they represent constraints on design which can affect potentially every engineering task.

For example, imagine a UserAntiStory which says, "Under no circumstances will the user be presented with a stack dump. If an unrecoverable error occurs, the system will log the error to a file, present a message asking the user to report it to development, and the system will remain in a consistent state, with only the erroneous functionality unavailable." There is no way that one person can be tasked with this effort and expect it to remain working in the face of future changes. Instead, it sets an architectural standard for error-handling which must be followed in all tasks. -- RussellGold

A: There might be straight forward engineering tasks that will address the stack dump issue. Say at the beginning of the run you arm the stack dump interrupt to field the interrupt, and put all functions in the system in a function vector, and the stack dump routine determines which function is running by inspecting the stack and kills that vector element, and people follow some rather simple conventions that sound a lot like "don't do stack dump error-handling".''

Q: I have no problem with the story card. I've always liked cards. Its what should be done with the card that bothers me. For example, in C++ there is a certain popular function (std::gets, inherited from C) that you dare not use because it lets abusers overrun the buffer and subvert the program. So, checking that it is not in my code is an ongoing process, not a simple schedulable task. -- DickBotting

A: Try solving this by enforcing an additional coding standard. Following the coding standards is one of the XP practices you do all the time. And it's quite easy to automate the check for it by writing a TestCase that would check that the function isn't called, perhaps by using reflection or even a grep script. If the test fails, you can't release that code.

There's not much in computing that doesn't succumb to OnceAndOnlyOnce, including security. Think kernel.

Q: How do you write test cases for a UserAntiStory? I don't think you can write a test case for "it is hard to break into the system" or "the system will never produce a walkback" or "no window will have both red and green on it". Or can you?

A: No, so those aren't stories. Making sure that you have an exception handler at the top level is something you can test however. So is scanning an encrypted message to make sure the original text doesn't appear. You could test that no window has red and green, but why would you want to. --KentBeck

No red and green: color blindness -- probably best rewritten as a functional test to see if the program can be used by a color blind person. --DickBotting

speaking of which... why must we have red x's and green checks for errors and passes in junit? :)

I set up LimitsOfUserStories to try to coalesce and sharpen the discussion that is now scattered over UserStory, UserAntiStory, TheExtremeProgrammingWayToHandleUserAntiStories, ThereAreNoUserAntiStories. --Alistair