QualityCode.com Essay: Business Functionality From Day One?

Some of the practices in Extreme Programming are widely known and accepted best practices, but others are quite radical. One of the radical aspects is developing applications one business story1 at a time, without regard to things like infrastructure. Let’s take a real-world example; one from the early days of a project that I happen to be working on at the moment.

It’s a typical desktop application, similar in many ways to a standard email program. Instead of email messages, it has folders containing “bulletins” that describe human rights abuses. It stores bulletins locally, and will also connect to a server over the internet, sending and receiving bulletins.

Since we’re running this as a (mostly) XP project, it was up to the customer to choose the highest priority story. After some discussion, he decided that the most interesting bit of functionality would be to bring up the main application window, with a list of bulletins.

Based on that, we tried to figure out what tasks2 would be required to complete that story. One thought was that the first task should match the first thing the application actually does, which is to allow a user to log in. Well, not quite. The very first time you run the program, there will be a screen that comes up to create the initial account. So we should start there, right?

Probably not. We can skip the initial account setup (since it’s not very interesting to the customer), and just hard-code one or more valid usernames. So the first task might be the log in screen…But that’s not very interesting to our customer, either. So we’ll also skip the log in dialog for now.

Ok, so we just want to display some bulletins. Don’t we have to implement the “Add Bulletin” screen first, to get some bulletins into our system? Nope. We can just display bulletins that we’ve created manually. Ah, so the first task would really be to create the database tables, so we have a place to put our sample bulletins, and then get those ODBC drivers working.

Wrong again. We don’t need a relational database or object database yet, and perhaps we never will. A flat file would do nicely. Come to think of it, we don’t even have stories for loading and saving bulletins yet, so we don’t need a file at all. We can just create some hard-coded sample bulletins in code, and display them on the screen. Perfect.

Let’s take a moment to reflect on what we’ve done: The customer just wanted to see some bulletins displayed on the screen. To get to that point, we avoided all these potential “obvious” tasks:

In this case, the customer got his first look at the system within a day or two, rather than having to wait a couple weeks. We can start getting feedback about the main screen and its look and feel. As developers, we are able to postpone our decisions about databases and file formats until we have a better understanding of the system.

A couple additional notes about this project: First, one of the biggest business needs was something to demo. It didn’t have to be too flashy, but needed to have some of the look and feel that we expected from the finished product. Second, we chose not to create a throwaway visual prototype. All of the code that we wrote that first day was production quality, with full unit tests. We created Bulletin and BulletinList classes, and those classes are still fundamentally unchanged two months later.3

There are many subtle but powerful aspects of XP, and this is one of them: Focus on delivering business value as quickly as possible. Question and challenge any task that doesn’t directly impact the story at hand. Don’t continue to build the system up in layers just because that’s the way it has always been done.



1 Story: An XP story is a description of one unit of business value. It’s similar to a “use case”, but is brief enough to be written on an index card. Often it is a single sentence, and sometimes it is a single word. Ok, it’s really more like the title of a use case than it is like an actual use case. The example here is “Display a list of bulletins in a multicolumn table”.

2 Task: Stories are sometimes split into tasks. A story represents value to the business. A task is a step that is necessary to complete a story, but which does not have business value on its own. Our example here was “Create a database”.

3 15 years later, those Bulletin and BulletinList classes were still in the code, with their original core largely unchanged.

This version includes minor revisions made on August 17, 2001 based on comments from the XP mailing list.