Vitaliy wrote:

> Aha! So this is what's creating the confusion. :)

Not really... see below.

> I am contrasting this with doing 100% (or close to it) of the planning
> and design work upfront.

I'm programming for 25+ years and have participated in several projects
small and big for a number of companies, but I've never seen that 100%
(or close to it) of detailed design was done up front. This may happen
in some government agencies or NASA or whatever, but possibly not even
there.

So... I'm not sure where it is that you disagree with me or Olin or
Rolf. You say that you do, but when talking about examples, it seems you
don't. Your common sense seems to prevail... possibly against your will
:)


> In fact, that is the whole point of agile contracts: they mostly
> describe the approach and the expectations, not the end result.

What's the difference between the expectations and the end result (that
supposedly satisfies those expectations)? If the end result doesn't
satisfy the expectations, there will be some kind of dissatisfaction,
which I'd say is not good. If it does much more than expected, it's
probably more expensive than it would have to be, which also tends to
create dissatisfaction. If it satisfies approximately the expectations,
it kind of used the expectations as specification. So what's the
difference between "specifying the end result" and "describing the
expectations"?


> Olin, well don't you ever start with a set of requirements for a
> product, and then add more features to this product? Couldn't you
> then say that the initial design had only a subset of the
> functionality? It is done all the time, you start with a simple
> design and eventually add more bells and whistles.

You said it: it's being done all the time. And it has been done all the
time. Nothing has changed here with Agile, at least not in my world. 

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist