Development Methods in the real world.
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
More information about the PLUG