Agile programming (was Re: [P|C] Banksel)
Vitaliy 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? :)
> 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.
You accused me earlier, of redefining terms. Now look at what you're doing.
There's nothing vague about the definition of the waterfall model. You have
your phases, and you do them in the prescribed order:
Once you're done with a phase, you can't go back. Once you start coding, you
can't go back to revise the specs. You don't test the code as you write it
(that's what the Verification phase is for, and as the chart shows, it comes
"Usually doesn't work well" is putting it mildly. How about "never works"?
>> 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
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
Do you not read any books on software development?
>> And I thought you said you agree with the Manifesto? :)
> 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.
>>> Like e.g. using a Gantt chart to make complex task dependencies
>> As long as you don't waste time projecting the deadlines six months
>> into the future, and creating a monster chart that has every single
>> trivial task listed, I don't have a problem with it.
> I'm glad to hear that you don't have a problem with me using Gantt
> charts. Seriously... :)
I'm glad that you're glad. :)
>> There are other, more effective ways to make dependencies visible.
> Like for example?
The information density used in this type of chart is higher, it doesn't
force you to assign dates to tasks, and it's "agile" in the sense that it
doesn't lock you into a timeline. In other words, it's more conducive to
getting a project done early.
Have you ever heard of JUnit, CUnit, or DUnit? 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.
You must have misunderstood what I meant. IIRC, you yourself expressed
surprise 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?
> 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. :)
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.
Not if you do it iteratively. :) You don't spend three months gathering
requirements, then three months writing tests, and another six months
writing the target code. What you do, is you define what a function should
do, write a test for it (which should fail initially), then write the
function. May only take you five minutes (we can call it a
Mind you, I myself don't do the "write the test" part yet, I went as far as
reading a book on TDD and playing with the DUnit. Then I jumped back into
embedded development, where existing TDD frameworks do not exist. Timothy
Weber gave me some great ideas last time we talked about TDD, which I'm
planning to put to good use...
>> 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. ;-)
Show me something better, and we can get together for a public burning of
the Agile Manifesto.
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