Re: [tlug] Giving a program priority briefly

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > You have a discussion about what the customer wants, get to the point
 > where you feel you agree, code up a bit of it, show it to him, and see
 > what he says. Repeat many times, and you'll end up with a very happy
 > customer.

Until you show him the bill ....

 > "Signing off" on a spec. is just a way to shirk responsibility and
 > shovel blame: it's there so when the customer says, "that's not what I
 > meant!" you can say, "hey, look at this document you signed."

But please to call it "our limited warrantee". :-)

If you're in a position to choose your customers, the approach you
advocate not only will lead to high quality, but (snotty comments
notwithstanding) it's very likely cost-effective, too, within the
constraints of a lifestyle business.

If you're not in that position (eg, corporate IT), though, without a
signed spec *you* are at risk.  Get their names on the dotted line,
then when they complain, jam the "contract" up their nose until it
comes out their boss's ears.  The next time, they *will* pay attention
and offer sensible comments when you sit them down to talk specs.
"Attitude is a tool."<wink>

 > (Well, perfect in the sense that it specifies exactly what the
 > computer will do. As a developer, you also need to make sure it
 > clearly tells humans what the intentions are.)

Third parties (whether your successor or a court of law) need a
*separate* statement of what the computer *should* do.  Otherwise they
don't know whether what just bit you is a ferocious roach or your pet
kabutomushi.

 > Perhaps we're just using the words slightly differently. I have lots
 > of specifications; they're just not written down as formal English
 > documents.

Both you and your customer are bearing risk of miscommunication, and
you need to deal with that risk in some way.  The process you describe
is one sensible way, but it's not always the most effective way,
especially not in organizations big enough to have separate IT
departments.  There are many cases (depending on the job and/or the
parties' personalities) where a formal spec process makes more sense,
and it has the advantage that it can be codified as a policy rather
than depending on "ningen kankei" going well.