piclist 2009\02\02\035846a >
Thread: Agile programming (was Re: [P|C] Banksel)
www.piclist.com/techref/microchip/devprogs.htm?key=programming
flavicon
face BY : 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.


{Quote hidden}

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
> place?

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.

Vitaliy

<2070AEB7C2FF4E7EB7B0408996F22373@ws11> 7bit

See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Agile programming (was Re: [P|C] Banksel)

month overview.

new search...