> >It is bad enough that non-XP approaches have to be characterized using
> >a pejorative term like "BigUpfrontDesign" and all of its negative
> >connotations. Do you have to misrepresent literally hundreds of
> >software development methodologies?
> It was not my intent to misrepresent any methodologies. It was my intent
> to characterize an iterative methodology as being better at delivering
> value to the customer *even if it is considered a failure*. AFAIK, over
> the years, methodologies have espoused shorter and shorter iterations with
> XP being the shortest so far. Maybe too short?
Most, but not all software development methodologies are iterative.
Specifically, they allow the developers to return to any point in the
life-cycle, introduce a change, and then propagate the effects of that
change. Saying that a life-cycle approach is iterative is a fairly
A sequential life-cycle is one in which, once a step is completed, you
are not allowed to return to that step, or to any step previous to that
step. Such approaches are only practical for very small projects, or
projects where powerful rapid development tools are available.
A recursive life-cycle is one in which the development process can be
reapplied to the results of the development process. All recursive
life-cycle approaches are also iterative, but all iterative life-cycle
approaches are not also recursive.
In classic iterative waterfall life-cycles, recursion usually takes
place within a phase (e.g., analysis, design, or coding). Iteration
also takes place within a phase. However, iteration can also cross
One of the primary differences between classic waterfall, and most
object-oriented life-cycle approaches is that iteration across phases
is the norm, rather than the exception. So when an OO person uses the
term "iteration," they usually have a very specific idea in mind, i.e.,
a collection of activities resulting in the delivery of a complete or
partial product. No restrictions are placed on what these activities
Industrial strength software engineering approaches almost always
require some form of "change management." There are entire books
dedicated to this topic. Among other things, change management concerns
itself with such things as:
- Clearly specifying what the change is.
- Determining if the change is worthwhile/permitted
- Tracking the progress of the change
- Ensuring that the change does not conflict with any other
- Introducing the change in a manner that ensures its effective
Back in 1979, on a Citibank project, I witnessed firsthand the problems
with uncontrolled change:
* Two different users contacted two different programmers at almost
the same instant in time.
* Unbeknownst to both the programmers and the users, each change
invalidated the other.
* In a room full of computer terminals, each programmer sat down at
a terminal and began entering the changes.
* When it came time to test the changes, the results were not what
* Each programmer tried different ideas, and each programmer was
After the two programmers had wasted about 2 hours, they finally
compared notes, and resolved the problem.
> >Are there actually people out there that believe that all changes are
> >forbidden in non-XP projects?
> Forbidden? No, not forbidden. However I do believe that many projects
> place barriers to change, for example the requirement that business must
> get approval from development before bringing changes to the table (IE
> they have to *ask* for the change.)
One thing that impacts this viewpoint is who is paying for the change.
In addition, is the person or organization paying for the change
willing to pay the entire cost of the change, regardless of the
magnitude of that cost.
The XP approach, to my understanding, says the customer pays for
everything. So, if a customer just happens to ask for a change that
will require a substantial expenditure of resources, then the customer
will have to "pony up." They can have all the changes they want. It's
just more money in the developers' pockets.
Of course, if any change, or combination of changes, is extremely
detrimental to the product and the project, what should the developers
do? Inform the customer of the ramifications, or simply go on
collecting money until the project fails?
However, consider, for example, the fate of people working on
fixed-price contracts. The customer comes to the developer with the
original idea, and asks for a quote. If both the customers and the
developers agree, the project commences.
Now, what should happen if the customer decides that they want a big
change, but the customer does not expect to pay any extra for that
change? Do you think that development should have anything to say about
whether the change should be implemented?
Quote:> Also, the insistence of designers to
> not allow the customer to see the product in its nascent form (so that
> they less time to evaluate the system.)
This doesn't sound like a good idea. Virtually all projects I have
worked on in the past 20 years made sure that the customer could see
the product, or a prototype of the product, whenever they wanted to or
Quote:> What we need is a methodology that explicitly states that the customer is
> always right, no matter how fickle or short sighted we may think him to
This methodology should also come with a "truth in advertising"
disclaimer informing the customer that they will pay for everything,
and that payment can be in many forms, e.g., money, time, product
quality, and product usability.
Quote:> If the customer turns out to be wrong, it's because the developer
> failed to give the customer the knowledge he needed. AFAIK, XP has come
> closest to this ideal.
From previous discussions with some XPers, I got the impression that
normally, XP does not have the requisite tools/methods/processes to
accomplish this goal. Now, of course, you can extend XP with whatever
is necessary, but you run the risk of moving very far away from
something you might call a "lightweight methodology."
Quote:> There are still, however, many questions. For
> example, I've read that the developers were being paid by IT (research?)
> but producing a product for Payroll. Who exactly is calling the project a
> failure, IT or Payroll?
This is a very legitimate question.
Edward V. Berard | Voice: (240) 271-3777
The Object Agency, Inc. | Fax:
Gaithersburg, Maryland 20885-4116 | Home Page: http://www.toa.com/
*Consulting, Training, & Research in Web/Internet/Intranet Technology*