Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
Gerhard Fiedler wrote:
>> Does this mean you finally want to go over the manifesto and the 12
>> principles, point-by-point? :)
> No, it doesn't. It was a question for you to answer. (FWIW, I responded
> to the first request where you asked me about my opinion on the
> principles, just a few minutes ago. You never asked this before.)
Sent: Monday, February 02, 2009 01:45
I don't think you ever responded to this message. I will try to find your
message where you said you address the points...
> DDJ notwithstanding, I'm currently working in the software industry and
> I don't see it. Given by the quick survey here of people working in the
> industry, you seem to be the only one accepting it. Doesn't look like
> it's "by and large" accepted.
So it would seem. The embedded community has been known for lagging behind.
> I think your picture that the ones who don't believe in it just don't
> know enough about it may not always be correct.
I only said that you don't know what Agile is, based on the statements
you've made, and the questions you've raised. I'm sure you've been in a
situation where someone was talking about something, and it was obvious to
you that the other person didn't really understand the subject.
This is getting absurd. :)
>> There's nothing vague about the definition of the waterfall model.
>> You have your phases, and you do them in the prescribed order:
> This is the Waterfall Model (capital letters).
There is no such thing. Read it for yourself, it's all lowercase:
> I was talking about the
> "basic principle" of it.
If you start reassigning meaning to words, you could be talking about Agile,
and calling it "waterfall model". Absurd.
You basically evaded my question. Call it "software engineering", if you
like -- what makes it different from engineering a building, in the sense of
applying prior experience?
>> Do you not read any books on software development?
> I do. Again, "development" and "managing" is not the same thing.
> Software development includes managing and architecture and coding and
> life cycle and maintenance and lots of things. We're talking here about
> a management style.
I disagree. Lean development methodologies cover all of the things you
mentioned. It's more about creating a paradigm of how a team organizes and
works, than pure "management". Refactoring, pair programming, iterative
development have little to do with management.
For some reason, I can't find any good critical chain graphs. But basically,
the reason it's higher density is simple: with a Gantt chart, time
increments are fixed, so a 1-day task is visually (physically) 100 times
shorter than a task that takes 100 days.
In a critical chain diagram, you have circles (or bubbles) that are
connected by arrows. Each arrow has the number of days required to complete
the task. One or 100, doesn't matter (visually).
I can send you the book, if you promise you'll read it. :)
>> Have you ever heard of JUnit, CUnit, or DUnit?
> I know them (well, not DUnit). Have you used them?
Yes, I played with the DUnit a little bit. As I mentioned before, I'm
totally new to TDD, so I'll skip the rest of the TDD comments (you may very
well be 100% correct, and I 100% wrong).
>> I prefer the agile principles, to the "every project is different, you're
>> your own, start from scratch" kind of advice. ;-)
> "Start from scratch" and "you're on your own" are additions by you.
> Nobody else claimed these. They don't have much to do with "every
> project is different".
They were implied. I asked you to share your experience, you said you can't
because every project is different. If you can't make any generalizations
(even conditional ones) about what constitutes good development practices,
it's as if you haven't learned anything from your previous experiences
(obviously not the case, I know you have).
>> Show me something better, and we can get together for a public burning
>> of the Agile Manifesto.
> Public burnings are something for fanatics. Whoever burns today the
> Agile Manifesto because the Static Manifesto says so will burn tomorrow
> the Static Manifesto because the Floating Manifesto says so. I rather
> read all of them, use what I learn from them at my judgment, and move on
> with what's important in life :)
What's important in life? :)
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