Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
Gerhard Fiedler wrote:
>> Well that's the point, most of what the agile methodologies are about,
>> was known for a long long time. Over time, the patterns emerged and
>> were used, and written about by different people. These same people
>> also realized that the traditional approaches to programming are
>> based on false assumptions.
> If those ideas have been known and used for a long time, how can they
> not be part of the "traditional" approaches?
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, and the likes of CMM or other "scientific" approaches to
> Note that I come from a
> background with relatively small companies and relatively few "studied"
> managers; most managers I've worked with or for were engineers,
> scientists, domain specialists rather than "professional" managers. They
> tended to do things in a way that made sense to them rather than
> following anything they learned. This may give me a different view of
> what is "traditional", but this is what it is for me.
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
>> [...] and I think therefore that one should at least consider what
>> they have to say.
> I do, I've read the Manifesto, I know about the movement and many if not
> most techniques, I consider them where I think they are appropriate.
> Most of the Manifesto I agree with.
I'm glad to hear that.
> But to me it's nothing
> overwhelmingly new.
So much the better, I like time-proven things. I'm also glad that some
people cared enough to write down this common sense wisdom, so that others
could take advantage of it.
>> The goal of software development is not to avoid expenses that result
>> from changing requirements. The goal of software development is to
>> produce business value.
> Of course, but quite often there are different (e.g. two) businesses
> involved that need to get value out of this. How to distribute the cost
> and the value is an important question, and often this question can't be
> addressed iteration by iteration.
I think it can. In fact, I think deciding it upfront is impossible --
because too many assumptions would have to be made.
> A thought here: changing direction in mid-course where you /could/ have
> gone in the required direction from the start is not creating business
> value, it's creating (unnecessary) cost. This is why it makes sense to
> have a requirements gathering phase, during which you find out what you
> can and need to know about the project, separate the hard requirements
> from the soft ones, and document at least the hard ones.
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.
> I know that
> documentation doesn't replace more direct communication, but it is also
> my experience that verbal communication can't replace written
> communication. Both have their place.
> Helping the client to understand the scope of their project before
> spending a lot of money on it is a good thing. This is not about
> programming; this is about understanding. I know that this is not always
> high on the priority list, but for me it is. More than once I've seen
> projects change direction drastically during this phase, because of
> previously unthought-of consequences. If someone had started coding
> before this, it would all have been wasted. No business value created,
> just the feeling of "doing" something, a paycheck for the programmer and
> cost for the customer.
You see, it is statements like this that make me feel that you don't really
know how Agile works (again, no offense). Before a singe line of code is
written, the project team has a meeting with the customer, where the scope
and cost are discussed. It is a highly interactive process, generally the
customer would write down the "stories" (features/usage scenarios) and the
team provides an estimate for each one. There is a lot of back-and-forth to
make sure both sides have a good understanding of the requirements and the
costs. Usually this is contrasted with a situation where the customer
basically hands off a spec to the developers, and says "get back to me with
a quote next week"
I think this is a great example of "plans are not important, planning is
important". To me, the biggest drawback of Gantt charts is that they make
you plan things way in advance, forcing you to make too many assumptions. A
couple of weeks into the project, the dates become meaningless.
Have you heard about Goldratt's "Theory of Constraints"? The charts that it
produces are far more useful, IMHO -- although the problem with dates still
How were things done before the software was written? Wouldn't it have been
possible to pick a few high-value features, and implement them?
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 gradually.
>> We've tried outsourcing a couple of times, providing heaps of
>> documentation and demanded strict adherence to the requirements. None
>> of the attempts were successful.
>> If we were to try outsourcing again, it would definitely follow an
>> agile approach.
> What went wrong, and how would you change it?
There were two major factors that contributed to the failure:
- We tried to document every detail upfront, literally spending several
man-months producing nothing but paper.
- 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" What's probably worse, we asked him to document everything he was
going to implement, before he implemented it.
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 requirements
- Have the developer pick a number of features "off the top" that he can
implement in two weeks
- Get regular (daily) software updates, and provide feedback to the
- Get working (see earlier definition) software at the end of the iteration
We could have launched this project when only about 60% of the functionality
>> There is a difference b/w project documentation, and user
>> documentation (see one of my previous posts). I'm all for user
> In many cases, the programmer is the "user" of something else (for
> example when programming a custom controller). In many cases, this
> "something else" is not sufficiently documented in order to write the
> desired program. These are cases where "gathering requirements" before
> writing code makes sense;
Sure. However, this can still be done in several iterations.
> for me, this is the original purpose of the
> requirements gathering phase of the waterfall model.
Not according to the definition:
> You seemed to have
> argued that gathering requirements before writing code is a waste of
> time, period.
I'm sorry you got this impression, it is completely false.
I don't have a problem with gathering requirements.
> I do it when and as much as it makes sense to me
> -- which is until I feel that spending more time on it would be
> inefficient. Where this point is, exactly, is IMO a matter of
> experience; there can't be a rule.
In Agile, the rule is simple: you gather enough requirements to do one
In some instances, especially for very complex projects, there is sometimes
what's called an "Iteration 0". This is when the high-level, architectural
requirements are gathered.
> I balance the (estimated) effect of
> the next so many hours thinking about and researching the project
> against the alternatives (like writing code). As long as this balance is
> positive, I continue to research, plan, document (which is nothing more
> and nothing less than keeping notes of the results of my researching and
> planning). For me, this is creating more business value than writing
> code that is based on wrong assumptions.
As long as you do this throughout the project (iteratively), your method
appears to be not much different from that advocated by agilists. The whole
point of limiting the requirements gathering phase to what's needed for one
iteration, is to minimize the number of assumptions.
It sounds like you and Oline have been spared the "scientific development"
approaches, then. Consider yourself lucky. :)
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