Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
Gerhard Fiedler wrote:
>>> Sure, Agile may fit the 'natural' model of how programmers work, but
>>> try to make a big bank look like a programmer!
>> I think the nature of the project is irrelevant. If you have a set of
>> practices that result in better software, why would it matter whether
>> this software is used to create financial models, control a
>> spacecraft, or run a website?
> IMO this is exactly one of the major management fallacies. The nature of
> the project does matter, the nature of the client does matter, the
> nature of (each of) the programmers does matter... heck, the nature of
> the manager does matter. It all matters, there is no silver bullet. The
> most productive teams (IME) are not the ones that follow an ideology, no
> matter how good the ideology, but the ones that efficiently adapt to the
> nature of everything involved.
Consider the possibility that we're both right. :)
"Plan is not important, planning is important" (Agile proverb). ;)
> I'm not sure, but the way I read the principles in the Agile Manifesto,
> this is something you could read into it: that the nature of the project
> /is/ relevant, and needs to be considered when creating the practices
> for that project.
I think of it as "adapting" the practices to a given project. All agile
projects share some basic features, it is what makes them "agile". They
follow from the principles, and do not change -- doing the project in
successive iterations, delivering working software at the end of each
iteration, etc. You could, however, adjust the duration of each iteration to
better suit your project.
Have you personally experienced this?
It seems to me that the test function is almost always simpler than the
function being tested. The classical example is a function that uses a
complex formula, and returns a value. You don't reproduce the formula in the
test function. It simply calls the user function, gets a value, and compares
it to a hand-calculated value. If they don't match, the test fails.
> To get out of this recursion, you need to have a means to write target
> programs without writing test programs first. Otherwise, you'd first
> need a test program for the test program, and a test program for that
> test program, and so on... :) And if you have a means to write a program
> without writing a test program first... why not use it in the first
I think you just created a straw man. :) I've never heard anyone recommend
writing a test program for the test program. What you have is the program
under test (the part that the users use), and the tests.
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