A Story Isn’t a Feature

Your business doesn’t want to hear about how you “delivered stories.”

story
Image source: AJC1, Flickr

The business wants you to deliver value, in the form of what they most likely refer to as features.

A story should trigger a conversation around a feature request. Your software product doesn’t contain stories, it contains features that help users accomplish goals.

Wikipedia describes a user story as “one or more sentences” that capture a user’s needs. Those sentences represent a brief description or summary based on the planning and preparation so far, and they are reminders of the conversation that you must continue to have around the feature you will build. The sentences are not the feature. They aren’t even the full story, in most cases, as it often takes the requester several more oral sentences or even paragraphs to say what they really want.

Why Does This Matter?

If you think about stories as a simplified form of a requirements document (“a couple sentences”), you’re constraining agile to be a small tweak to how you did things before, with a trendier name. That diminishes the most important aspect of how agile can help you deliver software successfully: Through continual collaboration and oral communication. Without understanding of the importance of collaboration, stories end up being another waterfall-like hand-off document.

On another front: Too many teams waste time over the wording of a story. It’s a discussion point, not an artifact. The “standard” story template should help you clarify feature requests by asking you to think about who needs them and why. But otherwise spending time on precise word-smithing of a story writeup misses the point. You’re going to discuss it, and you can iron out any ambiguities as you do.

Stories provide only minimal value as an artifact. The ensuing discussion is where the details come out. Unfortunately, most of us can’t fully recall details from a conversation a half year prior, or even a half month prior. Granted, the details end up embodied in the software, but source code more often than not does a poor job of expressing such details concisely and simply. Even programmers must sometimes spend hours to determine just what the code does for the smallest of features.

We need a better artifact than the few sentences that represent a story. Many successful teams have found that the best way to capture system behaviors is in the form of acceptance tests, best derived by use of acceptance test-driven development (ATDD) or BDD. The acceptance tests supplant the nebulous conversation with real meat. A test’s name describes the goal it accomplishes, and its narrative provides an example that quickly relates the details of system behavior. The set of test names describes the complete set of designed system behaviors. The tests capture the important detail behind the discussion triggered by the story.

A story is not a feature, and it should always trigger a conversation.

C++11: Using Lambdas to Support a Times-Repeat Loop

lambdaMore often than not, explicit for loops that execute n times usually need to know what what n is. Sometimes they don’t, in which case the for-loop structure seems mildly tedious. It’s certainly idiomatic, and you’ve seen ’em all a million times:

for (auto i = 0; i < 5; i++) {
   // code to repeat here
}

Still, having seen them all a million times, you’ve encountered many either accidental or purposeful variations:

for (auto i = 1; i < 5; i++) {
   // code to repeat here
}
for (auto i = 0; i <= 5; i++) {
   // code to repeat here
}
for (auto i = 5; i >= 0; i++) {
   // code to repeat here
}
for (auto i = 0; i < 5; i += 2) {
   // code to repeat here
}

The result: A for loop is something you must always pause to inspect. It’s too easy for your brain to miss one of these variants.

I’d much rather be able to simply send a timesRepeat message to an integer, as I can do in Smalltalk (Ruby has a similar message, times):

   5 timesRepeat: [ "code to repeat here" ]

In C++, overloading the multiplication operator would allow me to code something like:

   5 * [] { /* code to repeat here */ }

(The [] is the capture clause, which indicates that the following expression is a lambda, and also specifies how variables might be captured. In this case, the empty capture clause [] indicates that no variables are captured.)

A lambda function is of type function, therefore I can support the times-repeat expression with the following:

int operator*(int number, function<void (void)> func) {
   for (int i = 0; i < number; i++) func();
}

In other words, simply translate the lambda into the corresponding for loop, iterating number times, and calling func() each time, where number represents the receiver (5 in the example usage above).

A simple test demonstrates that the construct works:

unsigned int totalGlobal;

TEST(Lambdas, CanSupportedASimplifiedTimesRepeatLoop) {
   5 * [] { totalGlobal++; };

   ASSERT_THAT(totalGlobal, Eq(5));
}

(Use of the global variable totalGlobal allows writing the lambda expression without requiring variable capture.)

The resulting expression is succinct and even better than idiomatic, it’s obvious. I don’t think I’d go as far as to say that you should replace all for loops, just ones where access to the index is not required.

You could, of course. Here’s the result, a couple small tweaks to the first solution.

int operator*(int number, function<void (int)> func) {
   for (int i = 0; i < number; i++) func(i);
}

TEST(Lambdas, CanUnnecessarilyReplaceAForLoop) {
   unsigned int total{0};

   4 * [&] (int i) { total += i; };

   ASSERT_THAT(total, Eq(0 + 1 + 2 + 3));
}

The operator overload now simply passes the loop index i to the function being executed.

In the test, I now choose to use a local variable to capture the total. The capture clause of [&] indicates that any variable accessed by the lambda function is captured by reference. The function now also includes a parameter list, specifying in this case the index parameter of i.

I doubt I’d promote use of the second form (lambda with indexer) in production code. The first (times repeat) seems succinct and appropriate.

Atom