Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Saturday June 29, 2002
12:25 AM

Dear Customer, Write It Down

[ #6063 ]

I'm an XP practitioner. This means that, in my world, customers devise specifications by writing stories. Developers break those stories into the tasks required to implement them and base their time estimates upon those (adjusting for the actual time the previous estimates have taken). The customers order the tasks based on business value and risk. Software is delivered every n weeks, where n is a small number (two or three are fairly popular).

This has several advantages. First, it makes the actual work for each feature apparent to the customer. Second, it pushes the responsibility for technical risk on to the programmers. Third, it pushes the responsibility for scheduling and business risk to the customers.

Until tonight, I would have argued that another benefit is that it forces the customers to think about their requirements. After all, if something's not written on a story card, it won't be included in a task, will not be estimated, and will not be programmed. It effectively does not exist.

My current project has been moderately high on the risk scale, with the potential for big payoffs. I wasn't keen on it from a scheduling point of view, because there was also potential for failure. (The schedule was way too tight, and the business people have the nasty habit of claiming that nearly everything is of "highest priority".) We took it on anyway, because the reward would be amazing good will within an entire industry.

The schedule was and is tight, so that the first iteration doubled in size (already a bad sign), and the lowest-priority "emergency" feature will be delayed to the next iteration. Yeah, we're not even in the second iteration. We did hit the first iteration deadline just fine, and the customers have had the software for a while. Of the bug reports I've received, they've all been setup errors, easily fixed.

The problem is, I was celebrating the christening of the new wgz.org web server tonight, when I got a call at 8:30. Apparently, the customer's failure to give us an accurate specification several weeks ago has escalated into a crisis that means I "must" go into the office tomorrow to add a feature that never appeared on a story card. I do have plans for tomorrow.

My current plan is to go into work (and they are being "generous" in "allowing" me to come in at 9 am instead of 8:15, as is my usual habit). Because this feature was not on the story card, I feel perfectly justified in saying, "This is not an emergency. This is not my responsibility." I'm a nice guy, though, so I'll make the (small) database and code changes to store the data they want to collect. They'll have to wait until the next iteration (one week) to run reports.

To all of the customers reading this: If you ask me to build the software equivalent of a bicycle path, do not come up to me at the ribbon cutting and expect me to work overtime because you just remembered that elephants wander across it twice a year.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
    1. The client thinks up some project
    2. My boss writes a spec (usually without showing me) and the client agrees
    3. The client agrees to a budget that is too tight to include such luxuries as "testing"
    4. The client imagines that they are getting something that is 10 times better and includes features that aren't technically feasible
    5. I work really hard on the project and my boss smoothes things out with the client and it works out where everyone is happy
    6. I am proud of the end result
    7. I worry that we haven't tested anyt
  • Seems naive (Score:2, Interesting)

    • Until tonight, I would have argued that another benefit is that it forces the customers to think about their requirements. After all, if something's not written on a story card, it won't be included in a task, will not be estimated, and will not be programmed. It effectively does not exist.

    Non XP practitioners could say exactly the same thing except "on a story card" would be replaced by "in the functional specification".

    I think the XP practice of getting everyone together and putting requirements into