Vitaliy wrote:

> 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
story.

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.


>>> First of all, I thought we established that the waterfall model
>>> doesn't work in the real world.
>> 
>> You may have done that, but not me. I agree that the "pure"
>> waterfall model usually doesn't work well. But I also think that
>> there are projects where it is good to have an almost formal
>> requirements gathering phase before doing any coding, and there are
>> situations in general where completing one thing before starting
>> another is highly recommended. Which is the basic principle of the
>> waterfall model (according to me :).
> 
> You accused me earlier, of redefining terms. Now look at what you're
> doing. :)

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
> works"?

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.


>>> Second, Agile does not preclude one from using any tools or
>>> techniques, as long as they don't contradict the principles.
>> 
>> See, this is what I have a problem with. I could care less whether a
>> tool or technique contradicts the principles a few guys came up
>> with. If I have good reason to think it works (and I wouldn't think
>> that it does if I didn't think I had good reason :), I'm going to
>> use it -- and not waste a second of thought whether or not this
>> contradicts somebody's principles.
> 
> Your statement is so shocking, that temporarily I was at a loss for
> words (an unusual occurence for me). :) 
> 
> Say you worked with a younger engineer, who insisted on making his
> own mistakes, and trusting only his experience. So one day, he
> disregarded your advice, and ruined a transmission. Would it be fair
> to say that he is dumb, because he did not listen to someone with
> more experience (you)? 
> 
> Or how about an architect, who designs buildings based on what "makes
> sense" to him, disregarding the collective experience of hundreds of
> thousands of architects who went before him? 
> 
> What makes software development so fundamentally different from other
> engineering disciplines, that other people's (and even one's own)
> experience is irrelevant? 

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?
> 
> http://en.wikipedia.org/wiki/Critical_Chain_Project_Management
> 
> 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
animal. 

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
it. 

> [...] that TDD requires that tests be written *before* the function
> that is being tested. Or is this how it's normally done, in your
> experience?

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. 


>> IMO it is more important to have the tests written by a different
>> team than the target than when exactly this happens. Think about
>> it... in both cases, what you need is a clear picture of the
>> requirements. Whether you get this writing a test or writing the
>> target doesn't really matter all that much. What you have to do in
>> the end is debugging /both/ when you bring them together... there's
>> nothing that guarantees that your test application will be correct.
>> (And believe me, in all but the most trivial cases it won't be.)
> 
> I guess one can only hope that the wrong results won't match. :)

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
> testing.

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
program.


>>>> 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
requirements.


>>> 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 :)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist