Agile programming (was Re: [P|C] Banksel)
Gerhard Fiedler email (remove spam text)
> 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.
If those ideas have been known and used for a long time, how can they
not be part of the "traditional" approaches? Note that I come from a
background with relatively small companies and relatively few "studied"
managers; most managers I've worked with or for were engineers,
scientists, domain specialists rather than "professional" managers. They
tended to do things in a way that made sense to them rather than
following anything they learned. This may give me a different view of
what is "traditional", but this is what it is for me.
> [...] and I think therefore that one should at least consider what
> they have to say.
I do, I've read the Manifesto, I know about the movement and many if not
most techniques, I consider them where I think they are appropriate.
Most of the Manifesto I agree with. But to me it's nothing
>> Programmers never had a problem with requirements change.
> Gerhard, I don't know how you can say this, considering your
It's my experience, and I say this considering my experience. The main
problem, IME, has always been that continuing towards the earlier set
goal would cost less, and continuing towards the new goal will cost
more, and who is going to pick up that tab. (I've never found a
programmer on a fixed price contract complain about a requirements
change that takes out previously required features -- but this is not
the normal case.)
>> 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.
This phrase specifically was a little bit tongue in cheek... I meant
that there are programmers who will tend to implement things a bit
different from the requirements, for a number of reasons. Which amounts
to "changing the requirements".
>> 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.
Of course, but quite often there are different (e.g. two) businesses
involved that need to get value out of this. How to distribute the cost
and the value is an important question, and often this question can't be
addressed iteration by iteration.
A thought here: changing direction in mid-course where you /could/ have
gone in the required direction from the start is not creating business
value, it's creating (unnecessary) cost. This is why it makes sense to
have a requirements gathering phase, during which you find out what you
can and need to know about the project, separate the hard requirements
from the soft ones, and document at least the hard ones. I know that
documentation doesn't replace more direct communication, but it is also
my experience that verbal communication can't replace written
communication. Both have their place.
Helping the client to understand the scope of their project before
spending a lot of money on it is a good thing. This is not about
programming; this is about understanding. I know that this is not always
high on the priority list, but for me it is. More than once I've seen
projects change direction drastically during this phase, because of
previously unthought-of consequences. If someone had started coding
before this, it would all have been wasted. No business value created,
just the feeling of "doing" something, a paycheck for the programmer and
cost for the customer.
> Have you used Gantt charts for your projects? Was your experience
I don't use Gantt charts to create a detailed schedule of programming
projects. I do occasionally use Gantt charts to get a handle on the
interdependencies in situations with complex dependencies between
When you think "Before I go to LA next week Monday I need to have my
clutch checked. The mechanic said if there was a problem, it'll take him
a day to get the parts and another to fix it. I want to have a day
slack, so I better get my car to the mechanic by Wednesday max." you are
creating a Gantt chart in your head. A simple one, and you probably
won't draw it, but this is what you're doing.
If there are more tasks and the dependencies are more complex, actually
creating it to see how things /look/ helps me. "A picture is worth a
thousand words" or so they say, and a Gantt chart is basically a picture
of the schedule dependencies. For me it's easier to see what's going on
than having a dozen people fill my ears about what they need done before
they can do their thing; I'm not good in keeping such details in my
head, and a textual representation doesn't help me much. I generally
don't spend the time updating such charts as the project advances, at
least not regularly; for the projects I've been working on I didn't feel
this was worth the effort. But I did create some, and when I did, I
didn't feel that it was wasted effort.
> The material point is that the traditional waterfall approach is
> considered to be the industry standard. This is what they teach
> future engineers.
In fact, while I've heard a lot about the waterfall model, I've never
seen it implemented (maybe because the pure model is too far away from
reality). I've seen something similar once, in that a company spent a
few man-years gathering requirements before starting to write any code,
but I tend to think that this was a good thing in that case. It was not
only the program's requirements that they documented, it was the
company's billing procedures; they didn't have them documented up to
that point, completely and in one place. That seemed crazy to me, and
documenting them seemed to me a necessity that goes beyond the scope of
the programming project within which this was done, so the documentation
alone created business value (as I see it), independently of the program
that was based on this.
For me, this was a typical case of an extensive requirements gathering
What went wrong, and how would you change it?
> There is a difference b/w project documentation, and user
> documentation (see one of my previous posts). I'm all for user
In many cases, the programmer is the "user" of something else (for
example when programming a custom controller). In many cases, this
"something else" is not sufficiently documented in order to write the
desired program. These are cases where "gathering requirements" before
writing code makes sense; for me, this is the original purpose of the
requirements gathering phase of the waterfall model. You seemed to have
argued that gathering requirements before writing code is a waste of
time, period. I'm not saying that there are not people out there wasting
time by trying to define things at a point where whatever thy try to
define can't be known. But I stated some examples where it makes sense
to me to extensively gather requirements.
I try to understand as much as reasonably possible (and not more!) what
I'm going to program before programming it, and I call this generally
"gathering requirements" when talking about it. This term may come from
the dreaded (and considered outdated) waterfall model, but I don't
really care about this. I do it when and as much as it makes sense to me
-- which is until I feel that spending more time on it would be
inefficient. Where this point is, exactly, is IMO a matter of
experience; there can't be a rule. I balance the (estimated) effect of
the next so many hours thinking about and researching the project
against the alternatives (like writing code). As long as this balance is
positive, I continue to research, plan, document (which is nothing more
and nothing less than keeping notes of the results of my researching and
planning). For me, this is creating more business value than writing
code that is based on wrong assumptions.
>>> 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?
Non-ideologic, pragmatic approaches, more influenced by the individual's
experiences and preferences and the constraints of the situation than by
any school of thought.
In reply to: <CCD8ED5D78C6438389E2A9FBF6A49D82@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