Re: [tlug] Giving a program priority briefly

[Curt Sampson <cjs@example.com>]

On Tue, 12 Jun 2007, Josh Glover wrote:

> It is your job as an engineer to get the customer to sign off on
> *some* kind of spec, even if said spec is no more than a UI mockup or
> a workflow diagram. How can you design something that has a chance in
> hell of acceptance otherwise?

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.

"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."

> What happens when you quit and the next hapless engineer has to
> maintain your stuff? Won't it be easier if he has a spec to look at to
> see just what problem your code solves?

He's got one: the code is the prefect specfication. (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.)

> Wow. You've drunk the XP kool-aid deeply, I see. ;)

Yes.

> ...I just think that advocating a spec-free approach
> is a disservice to engineers less experienced than you. Not to mention
> a disservice to anyone who has to maintain your code.

Perhaps we're just using the words slightly differently. I have lots
of specifications; they're just not written down as formal English
documents. Perhaps that's not even the sense in which you're using it.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com