Agile programming (was Re: [P|C] Banksel)
Gerhard Fiedler email (remove spam text)
>> 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.
The set of practices that works well in one case may not (and probably
will not) work well in another case. Priorities are different,
constraints are different, goals are different... that's just how it is.
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.
>> Writing the tests first does not reduce bugs, it just means the bugs
>> are in the tests, *and* the code, and thus sometimes harder to find.
> Hm, having limited experience w/ TDD, I'll try to abstain from
> arguing, but it certainly sounds counter-intuitive.
It isn't that counter-intuitive when you consider that for non-trivial
programs, the tests are also non-trivial -- and often more complex than
the target program itself. So if you expect the target program to have
bugs (and that's exactly why you write the test program), you can expect
the test program to have /more/ bugs.
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
Mind you, I'm not against writing test programs before the target
program. But this method has its quirks, too.
In reply to: <B33AD9C151544D4ABE7FB6A0F97D230B@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