piclist 2009\02\05\053310a >
Thread: Agile programming (was Re: [P|C] Banksel)
www.piclist.com/techref/microchip/devprogs.htm?key=programming
flavicon
face BY : Vitaliy email (remove spam text)



Olin Lathrop wrote:
>> 1. At the end of each sprint, the customer gets working software. It
>> may even be useful enough to be deployed, even before the remaining
>> features are implemented.
>
> Making that a goal sounds like a bad idea for many projects because it
> promotes the slap it together versus careful architecture approach.
[snip]

You must have missed the explanation of "working software"  -- there is
nothing "slap it together" about it. The goal is to end up with code that
works, at the end of each iteration -- debugged, tested, and doing something
useful.

Deploying the software early is not a goal in itself, but it is a
possibility with Agile projects. The customer may decide that it has enough
features to be useful, and release it early. With waterfall and similar
methodologies, you cannot do this.


> Early on you may get what look like quick results.  However these don't
> have
> any depth.  As you try to slap on more features the lack of coherent
> architecture gets in the way.  Because nobody wants to throw out the
> existing work, it gets kludged and patched to add more features.  In the
> end
> you have a ball of bandaids if you ever get to the end at all.

Lean methodologies have been around for many years now, and obvious concerns
like this have been addressed a hundred times.

You seem to assume that "careful architecture approach" guarantees that you
don't end up with a ball of bandaids. The fallacy of this argument is that
you claim to predict the future. By definition, a project has many unknowns.
Design upfront means design based on assumptions (aka bad information).

Agile tackles the issue of uncertainty by splitting the project into short
iterations. At the end of each iteration, the team has learned something and
can make decisions based on facts, rather than assumptions.

One way to keep a project from becoming a ball of bandaids, is by continuous
refactoring. It is way better to rewrite the code several times, than be
locked into a rigid architecture that was based on wrong assumptions.


> Every consultant's worst customer is the one that says "We've got it 80%
> working, we just need you to finish the remaining 20%".  And of course
> they
> expect you to take only 1/4 of the time they have already spent.  Guess
> how
> they got into this mess, and why you should get out of there immediately?
> I'm sure everyone here that's done consulting for more than 2 years has
> heard this and knows exactly what I'm talking about.

I agree with you, but I don't see how this is relevant.

Vitaliy


<548640FAA93A4017877DDA2D45508208@ws11> 7bit

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 (was Re: [P|C] Banksel)

month overview.

new search...