Vitaliy wrote:
> The difference between planning for the first iteration and for the
> entire project is subtle, but very profound.
>
> When you're planning for the first iteration, you look at the big
> picture first. What are the high-level requirements? Ok, so this
> gadget must have an LCD, four buttons, a USB port, five A/D channels,
> and the firmware must be upgradeable.
>
> Now let's decide which features will be implemented in the first
> iteration -- let's say, reading the A/D channels and displaying the
> output on the LCD. These are the only things that need to be spec'd
> out in detail. On a medium-sized project (say, three months) this
> means that only..
>
>     (2 weeks/iteration)/12 weeks * 100% = 17%
>
> ... of the functionality must be hashed out in detail. It doesn't
> make sense to be hashing out the details of the secure bootloader and
> the kind of encryption scheme it will be using, until we get to it.
> High-level requirements are good enough for the first iteration. The
> bootloader may not be implemented at all, so creating the specs for
> it could end up being a complete waste of time.
>
> I am contrasting this with doing 100% (or close to it) of the
> planning and design work upfront.

You are confusing architecture with detailed design.  I never advocated
doing the whole design up front.  You do, however, have to have a good idea
of the architecture before designing individual pieces.

Using your example above, the gadget needs a LCD, four buttons, USB, five
A/D inputs, and a bootloader.  My point is you don't just want to dive in
writing the button code, for example, without having given thought to the
overall architecture.  There are many ways you could check the button state
and debounce it.  It could be done solely in a foreground loop, using
interrupt on change, sampling in a periodic interrupt, external hardware
aggregation, and probably a few more.  None of these are right or wrong by
themselves.  You can only decide the best way after looking at the whole
system.  That's what the architecture is all about.

You need someone experienced with the processor and its available hardware
to do a good job with this.  In this case I would probably run the USB
totally from foreground code and use one periodic interrupt to check and
debounce the buttons and initiate a new A/D reading.  Without a thought-out
architecture, which means knowing all the requirements up front to the
extent that is possible, you could end up with individual subsystems that
work but the whole not working when put together.  You might end up with,
for example, a A/D module and a button debounce module that both used the
same timer in incompatible ways.  It takes a higher level view of the whole
project beyond just the next iteration to prevent problems like this.

> I don't do consulting, but I believe you that this is probably how it
> is done in the majority of the cases. The problem is that initially,
> the customer does not know exactly what he wants. You can try to get
> him to think of everything, and commit it to paper. Or you can build
> a series of prototypes that gradually approach the final product.

You leave out the most common approach, which is you figure out what he
wants by making him pop up a few levels and describe his real problem.  Then
you come back with a proposal that may be totally different than what the
customer originally asked for,  You'd probably be surprised how often this
happens and how often you hear something like "Wow, yes, that's what we
*really* want.  We didn't think of it that way, and nobody else we talked to
mentioned anything like this.".  Frankly, being able and willing to force a
look at the true problem and think out the architecture up front is probably
the most important distinction between a good consultant and a bad one.

Mostly customers don't want implementations, they want solutions.  One of
the more important things a consultant does is to find out what the true
problems are and address those.  Never take the customer's initial word for
what he wants.  Sometimes they do know enough engineering and are familiar
with the range of possible solutions to understand how they want it done,
but this is really quite rare.  Sometimes it's not easy to get the customer
to pop up a few levels and describe the real problem because they often
don't understand it that way themselves.  Sometimes you realize as a result
you're in a no-win situation and you bail.  This is another point where
exprience is important.  Inexperienced consultants don't know when to bail
out and get stuck in bad situations as a result.  (Even experienced ones do
too occasionally, but less often.)

The point is this all takes up front planning to get to the architecture
stage before any implementation is started.

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

That's not a contract at all, or at least not one that most customers would
ever sign, and probably not most competent consultants either.  Customers
need to know what they will get, when, and how much it's going to cost.
Surely you can understand the need for that?  Let's say you asked me to
design the next OBD-II whizbang gizmo for you.  Would you be happy if I said
"Yeah, we can do that.  I'm not sure when it will be done, how much it will
cost, and we haven't agreed on most of the features, but send me $10/month
and I'll try to do something useful."?  Such arrangements do happen, but
they are very rare indeed.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist