Development Methods in the real world.

Steve smorrey at
Tue Sep 25 19:27:07 MDT 2007

Hello everyone,

As you may know I've been actively seeking work as a Software Engineer.
With the last several companies I've spoken with it seems they are
placing a huge amount of emphasis on trying to find people that know
how to work within their choosen development methodology.

I have seen companies that are using Agile, Scrum, XP, Waterfall,
Feature Driven Development etc.
In preparation for interviews I have been doing research on every
development methodology I can find, trying to figure out what these
are really all about.

It seems to me that most if not all of these "methods", are really
just buzzword filled metaphors management is using, and most can be
summed up in two words.  "Micro Management".

It appears that there are really only 2 distinct development methods,
really differing only in the order in which things are done.

Large Scale Development (LSD), Here you layout in detail everything
that a project should be/do in advance in as much detail as possible,
and work towards a single large monolithic goal.  I can see this as
useful for large projects where the design requirements are unlikely
to change, and requirements can easily be set forth in advance.  I may
be wrong here, but I think they generally call this the "Waterfall"

Iterative Development (ID), In ID you have a generalized end goal, and
you break it down into a series of milestones or iterations, then set
a time table for release of each milestone.  This is what I've been
the most involved in, and it seems to fit my programming style much
better.  The advantage here is that design requirements can change
easily and you are able to quickly adapt between iterations.  I'm
thinking this is the closest thing to Agile development that I have
actually done.

So I pose a question, for those of you who actually engineer software
for a living.
What is the reason for all of these other methodologies?
Do they truly have any major benefit, or are they as I suspect, more
of a hinderance than a help?
Finally, if you have actually been involved in one or more of these
methods, can you explain how it helped and/or hindered progress on
whatever project it was that you were working with?

Thanks in advance,

p.s. If the test case for Extreme Programming,  the Chrysler
Comprehensive Compensation System was essentially a failure due to
time/cost overruns.  Why are so many companies choosing to use it, is
there an example of a successful project or company that can be cited
that is using this in their day to day operations?

More information about the PLUG mailing list