email (remove spam text)(Olin Lathrop)
> Good question. I don't know why, I think they were practiced by a small
> minority, and the majority was educated and encouraged to follow the
> waterfall approach,
You keep saying this, but I don't think the waterfall method is taught like
that. It's usually mentioned as the "traditional" method, but if you look
under the hood of real projects you won't see one actually adhering to it.
> That's what I figured. I think of Agile as a set of practices that "make
> sense". It's only fault as far as I can tell, is the fact that it has a
> name. :)
Seriously, that is a real problem. Giving it a name immediately attaches
suspicion. It sounds too much like a cult. Part of the problem is that a
named set of rules sounds more rigid. The named set of ruled may even
largely be a good idea, but any rigid set of rules is going to cause
trouble. Common sense should always be the first rule.
> In fact, I think deciding it upfront is impossible --
> because too many assumptions would have to be made.
Of course you can't decide everything up front. But its very useful to know
where you're going even if you set out to implement a small subset then pop
up and look around again. There are many ways the small subset of features
could be implemented, most of them making it difficult to cleanly add the
Sometimes I get customers that think they know exactly what they want. I
always make them step back and explain the bigger picture. Most of the time
what they really want ends up different after some discussion. I don't want
to start implementing anything until I know the bigger picture it will fit
into. Only then can I architect the system properly so as to minimize
painting myself into a corner.
> Definitely. Agile development does not preclude requirements gathering.
> Have you ever heard of "Iteration Zero"? The big difference is that
> Agile gathers *just enough* requirements to get started, without trying
> to capture every single detail upfront.
If the "just enough" doesn't include the bigger picture and a good idea of
all the features required, then you'll likely end up painting yourself into
a corner with the early iterations. It's hard enough to avoid this even
when you do have the bigger picture, looking at the project with tunnel
vision pretty much guarantees it.
>> In fact, while I've heard a lot about the waterfall model, I've never
>> seen it implemented (maybe because the pure model is too far away from
I totally agree with Gerhard here.
> I am of the opinion that there don't exist any projects where 100% of
> the requirements must be gathered before the implementation work can
> begin. You can always start with a small piece, and build the software
Not if you want to be able to use the early work without architectural
changes or scrapping it completely. Also nobody said you need 100% of the
requirements up front. You do however need a good idea of the big picture
and all of what the system has to do at a high level, else you're going to
write a lot of throw-away code.
> - We tried to document every detail upfront, literally spending several
> man-months producing nothing but paper.
I'm sure some of that was good. It's a question of degree. That's a
judgement call you can't formulate a right answer to. Some projects do
require high detail up front. Often I see something the customer considered
a small detail dictating a large change in architecture. Part of the
problem is something that is a detail functionally may not be a detail to
implementation at all. Only the implementer or system architect can
> - We left the contractor out of the requirements gathering process. We
> basically handled him the specs, and said "implement it exactly as we
> tell you to"
If you had come to me with that I would have read the spec, made notes, then
insisted on sitting down with you and made you explain why you wanted each
of the details. Quite likely there would have been changes to the spec once
I understood what was really important to you and what was merely picked
that way to put something on the spec, and trading those off against
implementation constraints. If you refused to have this conversation I
probably would have walked away from the job.
> What's probably worse, we asked him to document everything
> he was going to implement, before he implemented it.
A competent consultant would have pushed back hard here and probably walked
away from the job if you persisted. This kind of micro-managing customer is
way more trouble than they're worth. It sounds like you got someone that
didn't know what he was doing or was desperate for work.
> The way I would do it now, is:
> - I would put together high-level requirements, spending not more than a
> couple of days.
> - Have a meeting with the developer, explain and prioritize the
So far so good.
> Have the developer pick a number of features "off the top" that he can
> implement in two weeks
Bad idea, at least in general. I've had many projects where the nature of
the architecture and the foundations that had to be built precluded
meaningful features within two weeks. Insisting on instant gratification
runs the serious risk of forcing a bad architecture and either living with
the resulting mess later or having to throw out the early work.
> - Get regular (daily) software updates, and provide feedback to the
Seeya. So long. Get someone else to do this job.
You are micro-managing again. There needs to be a ballance between your
need to have visibility into the project and the developer's need to have
you off his back and let him get some work done. Daily updates is going to
be way far off one end for the vast majority of projects. You are not doing
yourself any favors by insisting on this.
> We could have launched this project when only about 60% of the
> functionality was completed.
Then that should have been a milestone.
> In Agile, the rule is simple: you gather enough requirements to do one
Then what happens when the requirements for the next iteration come along
and you find you did the previous iteration the wrong way to fit on the new
features? You'll probably hear developers saying things like "I wish we'd
known ...", "If you'd only told us...".
> It sounds like you and Oline have been spared the "scientific
> development" approaches, then. Consider yourself lucky. :)
I'm not up on the latest buzzwords for sets of management rules all bundled
up neatly for easy consumption, so I don't know what you think "scientific
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000.
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the