Agile programming (was Re: [P|C] Banksel)
Gerhard Fiedler email (remove spam text)
I didn't say you did. You said that something changed with Agile (note
the capital A). According to the Agile Manifesto, it emerged in 2001.
Many people did what you described above before that date, so it can't
have changed with Agile -- it was already there. Redefining what was
done before the Agile Manifesto as Agile doesn't help anybody. Maybe
what those people did is among the roots of Agile, but it's not a
consequence of it.
Programmers never had a problem with requirements change. Heck,
programmers like to change the requirements as they program. The problem
always was with the question who pays for the changed requirements --
and the Agile Manifesto is suspiciously quiet about this :)
> However, the waterfall model (along with the Gantt chart) is still
> what they teach in project management courses in college, and from
> time to time I hear people advocating the "traditional" (fixed
> requirements, heaps of documentation) way of programming -- including
> here on the PICList.
Gantt charts are a tool that can make interdependencies visible before
they catch you, and this is something that can be useful in certain
situations. And it's not something that is opposed to an Agile approach;
they can work together. If you have dependencies, you better consider
them as early as possible. Part of my manifesto: Use your tools.
I don't care too much about what is taught in management courses in (US)
colleges -- I've been largely unaffected by them (and by the ones who
took them). It's also not really relevant for the issue. Part of my
manifesto: Don't wake your education literally.
Fixed requirements are a fact of life. If you outsourced the development
of a PC software to interface to one of your products, I bet there would
be some "fixed requirements". Speaking against "fixed requirements"
shows that you're not looking at the bigger picture. The problem are not
fixed requirements per se (they are just a fixed requirement :), the
problem are requirements trying to define what can't be defined ahead of
time -- which is a different issue. It's not a question of whether or
not to have fixed requirements, it's how to determine what are the fixed
requirements, and what is flexible. Part of my manifesto: "Something Is
Evil" smells like religion (and religion is not about solving
In order to understand some issues, you just need heaps of
documentation. I know that there are many people out there who never
read a manual of any of the things they own. I also know that there are
many programmers who never read a manual ("RTFM" is common in programmer
circles :). But I still think that "RTM" is the appropriate (and only
workable) solution for some cases -- and some complex requirements
require a lot of RTM, and heaps of documentation. Try getting a bunch of
programmers to write a decent transmission controller without reading
heaps of documentation. They'd probably iteratively wreck quite a number
of transmissions (and possibly cars, and maybe drivers) before they know
through iterative experience what they could've known by reading through
a few heaps of documentation :) Part of my manifesto: There's never too
much good documentation.
As for the waterfall model... maybe because I never worked in big
companies with "professional managers" I never had to suffer "management
abuse". But then, this is a personal choice, and maybe the ones who
complain about it have the same choice... Part of my manifesto: If you
don't like what you're doing, the problem is not with whatever it is
you're doing, the problem is with you doing it.
> Sure, but the prevailing wisdom is that you have to plan everything in
> detail in advance, fix requirements at the beginning of the project,
> and put provisions in the contract that deter the customer from
> making changes after the project's been started. Am I wrong?
Yes. It happened, in my career, but it wasn't prevailing.
In reply to: <C654244218634E8F9CC4D02698765BDE@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