piclist 2009\02\17\055445a >
Thread: Agile programming
www.piclist.com/techref/microchip/devprogs.htm?key=programming
picon face BY : Gerhard Fiedler email (remove spam text)



Vitaliy wrote:

> Olin Lathrop wrote:
>> "Just enough" sounds suspiciously like a judgement call to me.  
>
> Do you understand that there is a huge difference between "just
> enough planning for the project", and "just enough planning for one
> iteration"? This is a serious question, I'm trying to figure out what
> I need to explain better.

I think he does, and so do I. Two issues here...

One is that whatever is "just enough" (no matter for a project or an
iteration) /is/ a judgment call. This comes back to the earlier
conversation about experience: what is "just enough" /is/ experience;
there is no "scientific" rule about how much is enough.

The other is that there are many projects where a single iteration
doesn't produce any business value; business value is only generated
after reaching a certain threshold of functionality, which is so high
that there are a number of iterations necessary to get there. So you
know up front (or could know, if you planned that far) where you need to
go, and you're not as efficient as you could be if you don't plan that
far.


> Brooks says "build the first [system] to throw away; you will,
> anyway". His point is that you build the first one to learn from, and
> then you build the second one based on that experience.
>
> I don't subscribe to that point of view, but I agree that in general
> you can't design a perfect system on the first try.

Reality is that even though the second attempt usually would work out
better, often enough there are only enough funds for one shot. After
selling it for a while, there may then be a second chance for a shot
(but again only for a single shot).

But again (like with the testing before), Brooks's argument is circular.
If I build the first to throw away and the second is then "right", by
the time I build the second, requirements have changed, and the second
will be the new first... and so on. This is true, in that most of the
times I design a system, I learn something that I'd do differently in a
next design. But this is also irrelevant in that most of the time I
design a system, it's the only shot I've got -- because of budget
constraints.



{Quote hidden}

So you would start out by planning for all the required features,
several iterations ahead, "making planning decisions months ... in
advance"?


> Not in my experience. It is possible to start with a simple system
> with only a subset of the final feature set, and build/refactor it
> into the final system. Along the way, you may find that many of the
> features you considered important at the outset, are not. Certain
> features you may have left out initially because they seemed too
> difficult to implement, in reality turn out to be trivial to
> implement.

This doesn't seem to be what you suggested above... You suggested
planning ahead, many iterations, even planning for the NTP server and
Ethernet interface /before/ the initial iteration.

Gerhard
<zr2cpaaop8op.dlg@connectionbrazil.com> 7bit

In reply to: <1DF604613F0D48CE9196BD01198A4084@ws11>
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Agile programming

month overview.

new search...