Should you have to understand the application you're writing?

Extreme Programming has a concept of user stories, which express the customers' needs for the application you're writing. In XP, they're used only for estimating development times, yet have a very different feel than traditional requirements documents. It's very different to program to someone's narrative of how a system should work, as opposed to the traditional process of checking off items on a requirements list in your cubicle.

Now let's take this a step further and completely invert the process... instead of checking off your requirements, delivering the app, and documenting it for your users, what if you started by writing the manual, and used that as your requirements / design docs / user stories?

This approach is described by John Reynolds in his blog User Manual Driven Development.

Our development methodology was simple but effective... the marketing group wrote the deskmate user manual and we built the applications to match the manual. To be more precise, the marketing group would write a proposed manual, we'd negotiate with them over what could and what couldn't be done, and then we'd build to the manual.

I guess you could call this User Manual Driven Development, and I think that it still can be a very valid approach. In most respects User Manual Driven Development is very close in spirit to Test Driven Development - The function of the software is clearly defined, so it's very clear if the software doesn't do what it is supposed to.

In the spirit of TDD? I imagine the agile types are having a heart attack at the very thought of this, as it's clearly a case of Big Design Up Front, if not Waterfall. But still, if you think about it, you can see some appeal to this approach. One thing you might get out of this approach is a better understanding among your developers of what the app is really supposed to do -- beyond the clinical requirements list check-off -- since it's written from the point of view of how the user will use the the application, and implicit in that, what value they'll get out of it. As John points out:

It always stuns me when I encounter an engineering manager who believes that his staff doesn't need to know how to use the product that they are developing. I've heard people say "Just give us the requirements an we'll build it". I simply cannot agree with this philosophy... Requirements are never enough. Ever.

To write great software, you have to put yourself in the shoes of the user and walk a few miles. Perhaps it's a bit like method acting... Unless you "become" the user you're just going through the motions.

John points out that some of the best software is that which is made for developers, because developers know what other developers want and need. It's a lot easier for a typical developer to know if their IDE is useful than if they're building an accounting package, a non-linear video editor, a medical imaging system, etc. But if you have to build something like that, maybe a good first step is to start with a user manual for the finished project, so you can understand what the user will get out of the finished app. To steal a chapter from the famous Seven Habits of Highly Effective People, this is literally beginning with the end in mind.

But would it work for most people? What do you think?