Invisible <voi### [at] devnull> wrote:
> >    And it certainly doesn't help when project managers get evangelized into
> > believing that methodologies like "rapid prototyping" will help making
> > better programs.

> Uh, no, not really.

> Rapid prototyping /can/ be very useful for figuring out exactly what you 
> do and don't want from an application. And iterative prototyping (which 
> isn't the same thing) can be useful for trying out design alternatives. 

  Well, that's the theory, and that's why so many project managers get
infatuated with the idea. Also, it helps catching design mistakes early
in the project, saving a lot of work (because the later in the project a
mistake is caught, the harder and more time-consuming it is to fix it).
At least in theory. The practice, however, can be quite ugly.  What usually
happens in reality is something like this:

  First the programmer is given a basic ascetic description of the program,
and the programmer makes a small prototype. Then new ideas start pouring in,
"add this and this... and let's also try this small thing... add a button
that does this". Each time a new small feature request comes in, does the
programmer start from scratch, or does he simply add the feature to the
existing prototype? Most probably he won't start from scratch just to add
a new small feature.

  Thus the project advances. What started as a small, lean&clean prototype,
with nice little modules and functions, starts slowly but steadily growing,
as more and more small features are added and modified. Almost imperceptibly
the program grows into a humongous behemoth full of spaghetti code. The nice
200-line modules grow into huge 2000-line modules (and that's if the
programmer is being conservative and frequently splitting features into
new modules), and the dependencies between modules become more and more
complicated.

  At some point the program will have become a monster. Basically a huge
pile of small prototypes built onto previous prototypes, small kludges
added to previous kludges. The time has come to throw everything to the
trash and start from scratch. However, there are these things called
deadlines. Managers want results. They don't want programmers spending
the next two months starting the project from scratch. This is especially
so because the managers want *rapid* prototyping. They don't want to wait
two months for a new prototype.

  So the programmer keeps adding new features to the monster. This is
becoming increasingly laborious, but they try to cope. The end result is
a horrible and unmaintainable mess. Probably more horrible than what would
have been done with a more traditional development model.

-- 
                                                          - Warp

Post a reply to this message