Re: [tlug] Giving a program priority briefly

["Josh Glover" <jmglov@example.com>]

On 12/06/07, Curt Sampson <cjs@example.com> wrote:

> That's because, for typical business and productivity systems, a level
> of specification greater than "arm-waving" is, in the majority of cases,
> useless. Most clients, product managers and even developers who are
> also the product managers don't know all that well what they want, and
> thinking about it doesn't generally help that much. It's very often
> faster to kick around some ideas, do a rough implementation, examine the
> result, and run round that loop a few more times than it is to try to
> write a spec.

I disagree with this quite vehemently.

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?

I agree with your statement that there is value in a cycle of
prototype / present / accept feedback / make changes, but saying that
specs are worthless is nothing else than sheer laziness on the part of
the engineer. And it is not even smart laziness, since lack of a spec
will mean *more* work for you in the end. cf.

http://joelonsoftware.com/articles/fog0000000036.html
http://joelonsoftware.com/articles/fog0000000035.html
http://joelonsoftware.com/articles/fog0000000034.html
http://joelonsoftware.com/articles/fog0000000033.html

> Indeed. Which is why you need to get out there and work with them, and
> code with them, to see what they really do. It's exactly analogous to
> watching a user really use a spreadsheet, rather than just asking him
> what he wants.

Usability testing is very important, but it cannot replace a spec.
Speaking of which, here is a cool usability test that you can do with
no budget:

http://joelonsoftware.com/articles/fog0000000043.html (step 12)

> Unless by "specification" you mean "code in production" (which, after
> all, is the real "specification" by which the computer decides what to
> do), I think we're in disagreement here.

Ugh. :(

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?

> My usual "formal documentation" is a pile of index cards with roughly
> sketched out ideas on them ("stories"), and a lot of conversation with
> the client, every day.

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

I think a lot of the ideas in XP are cool. User stories are a big one.
But again (say it with me), they should not replace a good functional
spec.

> I don't expect anybody to be convinced by this post, BTW.

Your expectations shall be met, then. ;)

> In my experience, it's the sort of thing that's very hard to believe until
> you've participated in it yourself and seen it be successful.

No, I believe you, 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.

Cheers,
Josh