Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Giving a program priority briefly



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


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links