Software Reality

User Story != Use Case - but User Story != Story, Either

A user story is not a use case.

That might seem as obvious as saying "A door is not a cat", but there's enough scope for confusion - not just in the similar names - that user stories and use cases are often used interchangeably (when describing what to do next in a software project) when they probably shouldn't be.

Alistair Cockburn sums it up nicely: A user story is to a use case as a gazelle is to a gazebo.

But also:

A user story is not a story.

In other words - this is not a user story:

"The user types in a story and clicks Submit. The system publishes it to the website so that other users can read it."

It's really a use case. But it also doesn't help that there are many definitions of "use case", and many opinions on how much detail should go into one. But generally, the one consistent aspect of a use case is that it's a narrative: a description of a user's journey through the UI, and the system's responses as he clicks and types his way along: "The user does this or that; the system displays XYZ data in response. Next, the user does this... etc." In other words, the text of a use case is really a story.

A user story, meanwhile, is anything but a narrative. And this, I think, is the main source of the confusion. The name "user story" implies a story - a narrative. And it really doesn't help matters that the name is often shortened to "story". But a user story is anything but a story - at least in the narrative sense. I could see people starting to call narrative-based requirements "stories", but it's a false etymology, as they say.

'Design Driven Testing' now available as an alpha book

"Design Driven Testing", which I'm co-authoring with Doug Rosenberg, is due for release by Apress later this year.

It's a little unsettling to see chapters available so soon after writing them. But definitely a good thing.

Three chapters are available in Apress' Alpha Books programme so far... we've just submitted another two chapters for technical review, so these should land on the Alpha Book page pretty soon.

We've changed the chapters around a bit in the last few weeks. Here's the current line-up:

Part I - DDT vs TDD

1. Somebody Has it Backwards
2. Hello World Using TDD (implementing a "Login" story with TDD)
3. Hello World Using DDT (implement a "Login" story/use case with DDT)

Part II - A Walk Backwards Through the Mapplet 2.0 Project

(In this part of the book, we walk backwards through a real-life DDT project being run at ESRI Professional Services in Redlands, California. Our story begins with the completed product - code, tests, UI - and ends at the beginning, with the initial set of requirements. We demonstrate how tests were used to provide feedback at each stage of the project. The project's actually going on right now, and we're documenting its progress - meaning we're effectively writing this set of chapters backwards...)

4. Code and Finished Product
5. Detailed Design and Unit Testing
6. Preliminary Design and Behavioural Testing
7. Use Cases and Acceptance Testing
8. Test Cases and Requirements

Part III - Advanced DDT

9. Unit Testing Don'ts (Testing antipatterns)
10. Unit Testing Design "TODOs" (how to write "test-conscious" code)
11. How to write Enterprise Architect Test Case transform templates
12. When Designing for Testability is Taken Too Far

The book's also now visible on Amazon - which makes me think that I should probably get on and finish it now...

Oracle should cannibalize JavaFX Frankenstein

My latest article at The Register:

The biggest coup for JavaFX three years after its unveiling at JavaOne is its integration into Vancouver2010.com, in a spinning-wheel app that shows countries' medal counts dating back to 1924. It's a nice use of data visualisation, a cross between tag clouds and a time-traveling version of Risk. But oh my word, the jaggedness of the text. Don't these people know that Java can do antialiasing very nicely? Even the "Powered by JavaFX" logo has embarrassing color bleed.

The Winter Olympics app is a rare moment of fame for JavaFX, in an otherwise bleak and underperforming history. The brazenness of JavaFX.com suggests otherwise. It's all flashing lights and bold headlines, as if the marketing team are standing around Frankenstein's [monster's] corpse sending shockwaves of electricity into it and insisting: "Look! Look! It lives! No, really, it does!"

Read more...

Enterprise Architect 8.0 beta is out there

Many readers will already be familiar with Enterprise Architect (EA), which I've previously described as the best OOAD modeling tool this side of the Pleiades Cluster. But the new version, now in beta, promises to be something special.

There's a bundle of improvements listed on the beta page, but the "biggie" for me is the new Structured Scenario editor. Anyone who's written use cases and then wanted to derive unit tests (or acceptance tests) from them will appreciate the added precision that this editor provides. If you look carefully at the screenshot (click to zoom in), you'll see that the use case is divided into user actions and system responses. The simple act of separating these out opens up all kinds of possibilities - writing behavioural tests that cover each system response, for example; or turning the "user action" half of the use case into a Behavior Driven Development (BDD) scenario.

The structured scenario editor is also featured in the new Design Driven Testing book, where we're showing how to create test cases for the new structured scenarios, and then generate JUnit/NUnit/FlexUnit tests straight from the test cases; and how to tie it all into BDD (using JBehave and NBehave), for good measure.

Music to Program To

What types of music – genres, bands, composers – are best for programming?

The well-known “Mozart effect” suggests that listening to the great man’s music can improve your concentration and help you to make intuitive leaps… making his music perfect for programming to, surely? The study itself has been brought into question, but besides, Mozart doesn’t always hit the right note (so to speak). Programming isn’t just a single activity – different tasks take a different type of thought, so it follows that each needs a different style of music to nudge your brain into the right gear.

For those in a slightly trippy, Java annotation-mapping kind of place, I can recommend Psapp’s little-known album Tiger, My Friend. It’s an unconventional mix of (I assume) whatever object-that-makes-a-sound happened to be nearby while they were recording, put to acoustic rhythmic effect overlaid with sultry vocals; the result is somewhere between Penguin Café Orchestra and Frou Frou, in other words quite surreal, and it’s perfect for meta-programming.

Borders Express?

As Borders UK sinks weeping into administration, I found myself wondering: When was the last time I actually bought a book in a physical bookshop? It must have been years ago. These days it's too easy to mouse-click away and then wait a few days for your new possession to arrive.

So, e-commerce trumps street-commerce. But it doesn't have to be that way. In the spirit of the Bloke in the Pub Solving the World's Problems, here's what Borders (or whoever's left - Waterstones?) should do.

To start, we should ask how websites have managed to swipe the retail bookshops' lunch with such apparent ease. Here are the 3 killer advantages to shopping online:

• Convenience - just click to buy, no need to leave your chair and travel to a city-centre or out-of-town mall
• Choice - how can a high-street bookshop possibly compete with a range of 5 million or so titles?
• Discovery - the online format is perfect for searching, following "related product" links and stumbling across titles that you wouldn't otherwise have known about

Meanwhile, what's good about the high-street bookshops? Here are the advantages that they still cling to:

• No postage costs
• You get your book right away (assuming the one you want is in stock)
• You can talk to a member of staff (whether it's a knowledgable person is hit-and-miss)
• Social environment
• Physical - nothing quite beats browsing a floor-to-ceiling shelf of titles, picking up a book and thumbing through your potential new tome of knowledge (or of escapism, or whatever)

You would think that those would be quite compelling advantages; but the majority of them don't contribute directly to closing the sale, or discovering new products to buy. So for bookshops to compete with their online counterparts, they could do far worse than address the online advantages. One solution springs to mind: Borders Express.

(Or Waterstones Express, given that it's already too late for Borders in this country).

Amazon beats Waterstones/Borders hands-down for convenience and choice. WaterBorders (as I'll [in]conveniently call them for now) could build a hypermegastore across several floors with a massive choice of titles available. But they still can't possibly compete with Amazon's selection of pretty much every book currently in print (and quite a few that aren't, via their army of resellers). Even Foyles, which used to be considered the bookshop of bookshops, feels like a village shop compared with Amazon.

Rather than whimpering and changing nothing as their marketshare declines, I would love to see Waterstones/Borders/any remaining high-street booksellers go on the offensive.

The Worst of Humanity, The Best of Humanity

There are doubtlessly better, more contrasting examples out there, but these two stories on Slashdot, right next to each other, brought home how two big organisations, both of which purport to be there for the good of the people, can create such markedly opposing reactions in my stomach. While one is striving to explore the universe and expand on what it means to be human, the other is... well... just doing what it does.

Programmer Archaeology - The perils of joining a mature project

The majority of software projects are ongoing efforts - never ending cut-and-release marathons. New screens and functions are released on (or around) specific agreed dates, but the project itself keeps on going. So it’s far more common for developers to join a project mid-flow, with its own dusty corners that no-one dares to disturb, its homegrown O-R mapping frameworks, crusted together with the foibles and wrinkles of a dozen long-since-departed self-styled code gurus.

By contrast, starting a brand new project from scratch is a rare joy: the opportunity to set the standards, consider the architecture, evaluate the available technologies given the business requirements; and to produce clean, maintainable code that’s easily unit-tested.

Ah, that last one. There’s nothing quite like the pain of joining a “mature” project and discovering that unit tests were never even a glimmer in the eyes of the project’s founding coders; the forefathers who laid the treacle-like foundations for their successors to follow.

Like a Spanish explorer in a South American jungle, you’re unlikely to find a lost city of gold; instead, prepare to discover the overgrown remnants of one long-lost programmer’s vain attempt to add unit tests - a strained nod toward provable code quality, quickly abandoned when the poor programmer was beaten back by the tangle of dependencies, the onslaught of complex constructors and static initializer blocks like Aztec ghosts sending the programmer scrambling to the far end of the jungle.

Test Smarter, Not Harder

A culture of 100% test coverage has grown up around TDD. Code quality “measuring” tools such as Clover are used as a pugil stick to beat developers over the head with, if their code doesn’t measure up to an arbitrary set of metrics: and one of these is a measure of how much product code is covered by unit tests.

(Clover does have some pretty awesome features by the way, such as test optimization; but institutionalising test coverage as a measure of code quality isn’t one of them).

TDD itself can become a highly elaborate, labour-intensive way of creating code. It’s not uncommon to end up with far more test code (which the customer never gets to see, and which arguably doesn’t really “do” anything) than product code, which is what the customer is really paying for. Yes, the customer is also paying to have product code of a sufficient quality, and that’s what TDD addresses. But there has to be a better way of improving code quality with tests: a way that doesn’t soak up developers’ time and turn the tests into the main software deliverable, in the developers’ minds.

There are three main shortcomings to TDD:

1. It’s too time-consuming
2. You end up with too much test code, with code paths duplicated by different tests
3. The final amount of test code and product code that you see is disproportionate to the amount of refactoring/evolutionary design that went on to get there

To sum these three issues up: TDD is Too Damn Difficult; it takes too much effort to produce a bit of “production code” result.

Not using TDD – just writing tests after you’ve written some code – also has problems, in particular the aimlessness of this approach. It’s difficult to know when you’re done writing enough tests – in practice there won’t be enough time to hit 100% coverage, so the team must stop at some arbitrary timeboxed stage somewhere along the road. Most dissatisfying.

So here’s the idea. These shortcomings can all be addressed by first doing a small amount of structured up-front analysis and design, and identifying which parts of the code you’ll gain the most benefit from testing. We call this approach Design Driven Testing or DDT (the linked tutorial illustrates how to use an add-in for Enterprise Architect to automate much of DDT).

Take this sequence diagram, an overview of the code path for a hotel search (click the image for the full-size version):

Design Driven Testing - New book on the way

Just what the world needs, another book on Test Driven Development (TDD)??

Well not exactly... Along with co-author Doug Rosenberg we've recently signed up with Apress to write a book about automated testing (i.e., unit testing, acceptance testing, new-kid-on-the-block behavioural testing, and requirements testing).

But... this won't be your everyday "toe the party line" automated testing volume that regurgitates the TDD doctrine. Instead, we're making the point that TDD is, to put it mildly, ass-backwards. Tests shouldn't be the sole design driver; instead the design can be used to identify the key areas of the code to cover with tests. In other words the design should drive the unit tests, just as requirements drive the customer acceptance tests.

We've found that, while it has much in its favour, TDD represents too much work for what you get out of it. For example, we definitely don't recommend that you go all-out for 100% test/code coverage, because you'll never achieve it in the time available... so what's the measure of success? How do you know when you've written enough tests and it's time to stop? Instead, we believe you should "test smarter, not harder" - in other words, identify the key areas of the code that will benefit the most from tests.

There's a chapter on Design Driven Testing in our previous book, Use Case Driven Object Modeling with UML: Theory and Practice. However, in this new book we'll be exploring in much more detail the ideas and the practicality of automated testing, using a real-world, non-trivial project ("Mapplet 2.0") being developed at ESRI for a travel website. This project will use a Flex front-end hooked up to Java server code, which in turn connects to a hotel search XML database and ESRI's ArcGIS Server. So we'll be exploring how to go about unit testing an enterprise application with a mix of languages and technologies (just like the majority of real-life projects out there).

To top it all, Sparx Systems has developed an ICONIX Process add-in for their UML modeling tool, Enterprise Architect (EA), which automates many of the steps that we'll cover in the book. You don't have to use EA to use Design Driven Testing, but after seeing what's possible with the emerging tools support for the process, we believe you'll want to!

Stay tuned, I'll post more about the ideas behind Design Driven Testing over the next few days.