Agile programming (was Re: [P|C] Banksel)
Gerhard Fiedler email (remove spam text)
This is a good rule. It means we need to pay attention, even when using
Agile-approved methods. It means we need to pay attention to the
conditions and results. It means we need to pay attention where we start
making compromises, not because something better suited would not be
available, but because what's available is not a "recognized technique"
by whatever authority.
> That's a fair assessment of what I feel, and the way I read Gerhard
> and Olin's replies too. The last sentence is too broad though...
> there are rules, good rules, but like most rules, there are times to
> break them too. So, I guess it would be more accurate to say "there
> are guidelines, but all guidelines have an appropriate context".
Right... a context and limits.
For example, you posted a link earlier about documentation. This guy had
a diagram in his page, where both richness and efficiency of
documentation increases from paper over audio to video. Utter BS, this
diagram, if you start to analyze it.
First, he left out electronic written formats in the documentation graph
in his diagram. This is too strange, given that this guy is writing
about software. There is a huge difference between paper documentation
and (searchable) electronic documentation, even if it's the same content
and even the same layout. It's also probably the most commonly used form
of documentation, at least in electronics and software. So why would he
leave it out? Where would he put the richness/efficiency spot of the
most commonly used documentation medium?
Secondly... efficiency? Can you imagine the "efficiency" of PIC
datasheets in video? Give me a break. Some people say that there is a
whole generation of near-analphabetics growing up, with an attention
span that goes from one commercial break to the next and not much
further, but this doesn't mean that written material is not efficient if
you can use it. I generally can read (and understand) an issue in about
a tenth or a fifth of the time it would take me to work through a video,
and probably most people with decent self-learning skills are similar in
this respect. FWIW, whoever is not good with written stuff shouldn't be
in writing software in the first place. So audio and video in this
respect is just silly. (And note that I'm not talking about the second
graph in his diagram, which is about something else, something more
interactive, "modeling" IIRC. I'm talking about the one he calls
"documentation", which is supposedly about documentation.)
No doubt for /some/ documentation situations a video is more
"efficient", but for issues related to software? IME rarely. So there is
definitely missing some context about the efficiency of different media,
and I think applying the usual software documentation context, for me at
least video and audio (even worse) are very inefficient media.
>> In addition, the statements you guys made reveal that you don't
>> really know what Agile is. If you don't know what it is, how can you
>> make judgements about its effectiveness?
In this thread, I commented almost exclusively on your comments (which
includes what you say that Agile is for you), not about Agile in itself.
I don't make judgments about Agile, but comment on specific
affirmations, independently of where they come from. (Like you said that
the Manifesto changed the management world, and I said IME it didn't
because the stuff written there sounds nice but not that new in the
context of the managers I've worked with and for. This doesn't say much
about what I think of Agile and what are considered Agile techniques.)
> For the record, I live in Canada. It is great, and is good for
> everyone. If where you are works for you -- there's no reason to
> change if you are happy where you are. If, on the other hand, you are
> dissatisfied with the status quo (like I was before I came to
> Canada), I would encourage you to emigrate. New places, especially
> ones that have a catchy name that begins with a capital letter,
> usually meet with resistance -- it is to be expected.
Ah, and Brazil... ever thought about moving here? :)
In reply to: <498AE2D6.firstname.lastname@example.org>
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