piclist 2009\02\02\022916a >
Thread: Agile programming (was Re: [P|C] Banksel)
face BY : Vitaliy email (remove spam text)

"Gerhard Fiedler" wrote:
>> I never said that Agile was new.
> I didn't say you did. You said that something changed with Agile (note
> the capital A).

For me personally, and the way we do things at work -- when we learned about
Agile, and started implementing some of the concepts.

> 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.

Well that's the point, most of what the agile methodologies are about, was
known for a long long time. Over time, the patterns emerged and were used,
and written about by different people. These same people also realized that
the traditional approaches to programming are based on false assumptions. So
these folks got together to share their ideas, and came up with the Agile

I'm usually the first one to smirk when people appeal to authority, but in
fact these guys are industry leaders, they have been in the business of
software development for a long time and I think therefore that one should
at least consider what they have to say.

> Programmers never had a problem with requirements change.

Gerhard, I don't know how you can say this, considering your experience.

Changing requirements is the #1 complaint I get from new engineers (after a
while, they get used to how we do things). "But last month we decided..."
Who cares what we decided last month. We're not slaves to our past
decisions. The situation has changed, we learned something new, Joe
discovered a better way to implement the feature.

> Heck,
> programmers like to change the requirements as they program.

Not around here they don't. :) I thought it was common knowledge that
programmers are supposed to hate change.

> The problem
> always was with the question who pays for the changed requirements --
> and the Agile Manifesto is suspiciously quiet about this :)

The goal of software development is not to avoid expenses that result from
changing requirements. The goal of software development is to produce
business value.

{Quote hidden}

I can only tell you what I know from experience, and my personal experience
is that Gantt charts are a waste of time. Also, I regularly visit a local
university, and we've been sponsoring student teams for almost a year now.
The story is the same every time: the students put together an elaborate
Gantt chart, but end up throwing it out the window once the schedule slips
and/or requirements change.

Have you used Gantt charts for your projects? Was your experience different?

> 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.

The material point is that the traditional waterfall approach is considered
to be the industry standard. This is what they teach future engineers.

> 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".

We've tried outsourcing a couple of times, providing heaps of documentation
and demanded strict adherence to the requirements. None of the attempts were

If we were to try outsourcing again, it would definitely follow an agile

> 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.

I agree. Which leads me to believe that you misunderstood what I was talking
about. :-)

{Quote hidden}

There is a difference b/w project documentation, and user documentation (see
one of my previous posts). I'm all for user 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.

I like your manifesto.

>> 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.

What was prevailing, then?


<CCD8ED5D78C6438389E2A9FBF6A49D82@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...