Development Methods in the real world.

Levi Pearson levi at cold.org
Wed Sep 26 10:35:36 MDT 2007


Shane Hathaway <shane at hathawaymix.org> writes:
>
> The waterfall methodology was developed at IBM.  IBM used it for all
> their projects, but in the end it proved costly and not adaptable.
> Today IBM generally encourages everyone to avoid it.  Most of the new
> methodologies are a reaction to the flaws in the waterfall methodology.
>  OTOH, many elements of waterfall methodology are as important and true
> as ever, so there is a lot to learn from waterfall.

I think you're exactly right here.  The 'waterfall' method encompasses
all the things you need to do to have a successful product.  Its
failing, however, is the strict ordering it places on them.  Agile
methods generally provide a structure for doing multiple waterfall
phases at once, so that you can quickly discover the inevitable flaws
in your execution of those phases.

>
> That's the way it looks to a coder, but you're leaving out the customer
> communication details.  To understand the differences between different
> methodologies, you must consider the patterns of communication with the
> customer.  When communication with a customer breaks down, you can often
> fix the communication patterns by modifying the development methods.

I also think it's useful to think of software methods as project
management paradigms that are somewhat analogous to how we use
programming paradigms.  Just as it's possible to write a program in
assembly language with no pre-planned or particularly evident
structural patterns and have it work properly, it's possible to run a
software development project without any particular management
pattern.  However, you can get a lot of benefit both while you're
programming/managing and in later analysis of how you did if you
follow some sort of a design/management paradigm, such as OOP or an
Agile process.

                --Levi




More information about the PLUG mailing list