Agile programming (was Re: [P|C] Banksel)
Gerhard Fiedler email (remove spam text)
> Gerhard Fiedler wrote:
>>> I was saying that for the things that are always true, the nature of
>>> the project is irrelevant.
>> What are the things that are always true?
> 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.)
>> Really, I haven't found much in this category. People come and go,
>> and schools of thought, too -- this is probably one :)
> Only time will tell, right? :) It's been eight years since the
> manifesto had been drafted. Agile is by and large accepted by the
> software industry (according to a DDJ survey), and is trickling down
> to the embedded software industry. I predict that it won't be long
> until you have a personal encounter with it.
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.
But I've had my encounters with it, possibly before you. It's around, as
you noted, since 2001. Fact (of experience) is that it doesn't work as
claimed in many situations, and that's why my encounters with it were
more peripheral -- as seems to be the case for almost everybody I know
in the industry.
It probably did have some influence, though. But that's a different
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 didn't redefine, I defined what I'm talking about. That's different.
> 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). I was talking about the
"basic principle" of it. Which is something different. You have a Yageo
resistor, and the basic principle of a resistor; there is a difference.
> "Usually doesn't work well" is putting it mildly. How about "never
Right. You could have noticed that I try to abstain from absolutisms; I
think they are (mostly :) evil :)
But the Waterfall Model is different from the basic principle of it.
You're mixing domains. We are talking about managing people. You are
talking about the design of a transmission controller or a building.
These examples are analog to the architecture of a program, not analog
to the way the programming team is managed. Managing a programming team
and a builder crew is not that different, but of course designing a
program and designing a building is different. But then again, there is
a similar difference between managing a builder crew and designing a
building on one side and between managing a programming team and
designing a program on the other side. But managing and designing are
two different domains, with different rules.
> 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.
Talking about management, I don't consider only the Waterfall School and
the Agile School. There are others, and there are techniques that are
not really part of any specific school.
Managing people is less "objective" than controlling transmissions or
designing houses or architecting software. While there are certain
rather objective principles that determine the static properties of a
building, there is much less objective knowledge about managing the
people involved in building it.
>> I said I can agree with most that's written in the Manifesto. But the
>> Manifesto is rather generic; you can bring it in alignment with a
>> lot; it seems with more than most would consider "Agile".
> Gerhard, you're very slippery, you know that? :) Give me one example.
Just sent you a few.
>>> There are other, more effective ways to make dependencies visible.
>> Like for example?
> The information density used in this type of chart is higher,
When you first mentioned Goldratt, I already checked this out, but I
didn't see (and still don't see) a chart there. So I don't really see
what you're talking about.
> Have you ever heard of JUnit, CUnit, or DUnit?
I know them (well, not DUnit). Have you used them?
Single-threaded unit test is one thing, multi-threaded unit test is
another thing, but testing the real problem (which is integrating
several units, or the whole application) is a completely different
Besides, you almost never can base a unit test on project requirements
(because the units are way below the project requirements), so if you
want to base tests on project requirements, you need to focus on a
higher level of testing.
> I don't think it makes sense for me to spend my time basically
> paraphrasing the basics of TDD. Tests and the software under test,
> are different things.
If you say so...
> You must have misunderstood what I meant. IIRC, you yourself expressed
> surprise [...]
No. No surprise anywhere. Just some disagreement. And other than just
stating that I'm wrong, you didn't really come up with an explanation
why (much less a convincing one).
Again, just because I don't completely agree with TDD, everything that
has been claimed about it (including by you) doesn't mean I don't know
> [...] that TDD requires that tests be written *before* the function
> that is being tested. Or is this how it's normally done, in your
I don't quite understand the question, especially because it seems to be
based on a "surprise" that I didn't have. It may help if you didn't
always assume that we (who don't agree with everything you write) just
don't do so because we don't know enough about Agile, TDD, whatever.
It happens. That's why still more verification (outside of both DUT and
test) is necessary.
> FWIW, TDD tends to assume that the tests reside inside the program
> under test, preferably in the same module/class that the tests are
Again, this has some merit, but is very limited, especially in
multi-threaded and real-time applications. Another major limitation of
this is that it generally doesn't test project specifications, as these
by definition don't apply to any single unit, but to the overall
>>>> Where do the tests come from?
>>> They are based on the requirements.
Which requirements? It is statements like these that made me think that
you didn't talk about unit tests. You test architectural assumptions
with unit tests, not project requirements. Go back to the example of the
multi-threaded queue... the test doesn't have much to do with project
>>> Simple tests don't cost much, and can be useful.
>> Of course. This is a perfect application of the "it depends" principle
> I prefer the agile principles, to the "every project is different, you're on
> 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".
> 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 :)
In reply to: <867E708BEDAA4A9784A5452CDA4F36B8@ws11>
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