Re: Re: Re: What do they want?

Yeah, they will. But, that's when you say: I met the design. If you want to change the product, please find the hours for me to:

Change the design
Change the test-suite
Develop
Change the documentation

Treat it like a "real" product and you'll find that they will, too.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Comment on Re: Re: Re: What do they want?

Replies are listed 'Best First'.
Re: Re: Re: Re: What do they want? by grantm (Parson) on May 02, 2003 at 01:57 UTC
True - they need to accept that you delivered what they said they wanted and if they now want something different, someone has to 'pay' for the effort to implement it. But, in my experience, it is important to set the expectation at the outset that this is what will happen, so the initial estimate includes a proof of concept or pilot and a couple of iterations. People almost never know what they want until they have something that they can play with. Then they are able to say "yes, this is what I want except ...". The problem with documenting a spec before starting work is that it is very hard to strike a balance between the document being precise enough to be useful (and uncontestable after the fact) and the document being accessible enough that it will actually be read and understood. If I write a spec that someone misinterprets and signs off in error, then I should share the blame. I do agree the importance of documenting things up front. However the point of documenting is so that everyone's expectations are in sync and (IMHO) one important expectation that everyone should have is that developing a solution is an iterative process.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: What do they want?
by grantm (Parson) on May 02, 2003 at 01:57 UTC

True - they need to accept that you delivered what they said they wanted and if they now want something different, someone has to 'pay' for the effort to implement it. But, in my experience, it is important to set the expectation at the outset that this is what will happen, so the initial estimate includes a proof of concept or pilot and a couple of iterations.

People almost never know what they want until they have something that they can play with. Then they are able to say "yes, this is what I want except ...".

The problem with documenting a spec before starting work is that it is very hard to strike a balance between the document being precise enough to be useful (and uncontestable after the fact) and the document being accessible enough that it will actually be read and understood. If I write a spec that someone misinterprets and signs off in error, then I should share the blame.

I do agree the importance of documenting things up front. However the point of documenting is so that everyone's expectations are in sync and (IMHO) one important expectation that everyone should have is that developing a solution is an iterative process.

[reply]