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



Olin Lathrop wrote:
>> We do just enough planning for one iteration. There's nothing
>> ambiguous about it.
>
> "Just enough" sounds suspiciously like a judgement call to me.  I think
> it's
> impossible to discuss what just enough is in the general case since every
> case is so different.  Without a specific project, we're all just making
> hot
> air.

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.

In the first case, you're making planning decisions months, and maybe years,
in advance. In the second case, you're only doing enough planning to carry
you until the next iteration meeting (one or two weeks away).


>> We don't write specifications for features that
>> will not be implemented in this iteration.
>>
>> Does this make sense?
>
> No.  I keep saying this and you keep not addressing it, so I'll try one
> last
> time.

I'm doing my best, but of course if you feel like I'm not addressing it,
then I'm not doing a good job. You can help me by making an honest effort to
understand, and telling me exactly what does not make sense to you.


> In system design you need a good idea what the whole system needs to do
> before you can start designing the first piece.  This is because there are
> many ways the first piece could be designed, but some ways allow that
> piece
> to fit into the larger system nicely while others proclude it.  Without
> the
> larger context you run the risk of painting yourself into a corner during
> early development.

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.

So what we do, is accept that change is inevitable, and make an effort to
isolate and contain it by employing appropriate design practices. We don't
build one system, throw it away, and write a second one from scratch. What
we do is learn throughout the project, with every iteration building on top
of the ones preceding it. Refactoring is key, it's the one technique that
allows the project to gradually be chiseled into its final form.


{Quote hidden}

Your example is understandably contrived, but here is how I would approach
this project:

First, I would create a quick sketch on a napkin or better yet, a
whiteboard. I would draw a quick block diagram, and a simple drawing of the
product's appearance. "Is this what you want? Do you want 12 hr or 24 hr?
How many users would this NTP server serve? Etc."

Once I think I understand what you need (after 30 minutes of sketching and
asking questions), maybe I could even construct a simple cardboard model.
Does it look like you imagined it?

We could breadboard a part of the circuit, let's see if the 7-segment LED is
big enough/bright enough. "You want a different color? No problem, let's try
this one. Looks OK? Great!"

I would get your feedback as I sit down to do the schematic, and later the
layout. In parallel, I could put together bits of working code, and
demonstrate them to you (sync code, UI, NTP server).

With every new draft, I would get closer and closer to the final product,
without wasting a lot of effort implementing something that I *think* you
want.

------

What I would *not* do, is try to commit every single detail down to paper,
before doing any actual work.

By the way, this is really how we approach things at work. Initial planning
meeting, even for projects that take many months to complete, takes no more
than three hours. We gather only enough requirements and do just enough
planning, for one week (our engineering team is small, and our iterations
are shorter than the "normal" agile ones).


>> This is similar to the YAGNI (You Ain't Gonna Need It) principle: you
>> don't program features that you think you may use, you only code the
>> ones that you know you're going to use.
>
> Code yes, but you do have to architect the system for the full feature
> set.

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.

We've done it, and I've seen other companies go through the same process.

Vitaliy

<1DF604613F0D48CE9196BD01198A4084@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

month overview.

new search...