http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7

"The old [engine] had grown to resemble the closing stages of a game of 
Jenga, in which making any change was a delicate operation that risked 
bringing the whole edifice crashing down. In particular, there were a 
dozen open bugs [...] that I had no idea how to fix."

I think that's a really amusing quote. How many of you have worked on 
programs that look like "the closing stages of a game of Jenga"? :-D

Post a reply to this message

On 11/10/2010 5:47 AM, Invisible wrote:

> I think that's a really amusing quote. How many of you have worked on
> programs that look like "the closing stages of a game of Jenga"? :-D

I'm working on one right now.


-- 
~Mike

Post a reply to this message

>> I think that's a really amusing quote. How many of you have worked on
>> programs that look like "the closing stages of a game of Jenga"? :-D
>
> I'm working on one right now.

My God have mercy on your soul.

Post a reply to this message

Invisible escreveu:
> http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
> 
> "The old [engine] had grown to resemble the closing stages of a game of 
> Jenga, in which making any change was a delicate operation that risked 
> bringing the whole edifice crashing down. In particular, there were a 
> dozen open bugs [...] that I had no idea how to fix."
> 
> I think that's a really amusing quote. How many of you have worked on 
> programs that look like "the closing stages of a game of Jenga"? :-D

I believe any software eventually reach that stage.  The more you add, 
the more complex, the more resistent to change, the more ugly, the more 
fragile to subtle bugs.  Its inertial mass at work...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> I believe any software eventually reach that stage.  The more you add, 
> the more complex, the more resistent to change, the more ugly, the more 
> fragile to subtle bugs.  Its inertial mass at work...

  And it certainly doesn't help when project managers get evangelized into
believing that methodologies like "rapid prototyping" will help making
better programs.

-- 
                                                          - Warp

Post a reply to this message

>> I believe any software eventually reach that stage.  The more you add,
>> the more complex, the more resistent to change, the more ugly, the more
>> fragile to subtle bugs.  Its inertial mass at work...

I would argue that it varies depending on what precisely you're trying 
to add, how carefully you add it, how well the program was designed in 
the first place, how often you go about code reorganisation / tidy-up, 
and so forth. I don't think it's as simple as "all code eventually 
becomes unmaintainable" (although there's certainly a very considerably 
tendency in that direction).

>    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. 
But no, Rapid Application Development and similar management buzzwords 
do not magically solve computer programming. (Quite the contrary, 
usually...)

Post a reply to this message

Invisible wrote:
> But no, Rapid Application Development and similar management buzzwords 
> do not magically solve computer programming.

Actually, I come to the conclusion that if you look at most of the XP and 
other Agile-style stuff, the main thrust is to let management slack off of 
managing, and have employees who are decent coders but shit programmers, and 
still think you can create something usable. Which might work if there's 
only one customer for the software.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

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

>> 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.

Yeah, that's the theory.

> At least in theory. The practice, however, can be quite ugly.  What usually
> happens in reality is something like this:

 From what I've seen, the theory goes wrong when one of the following 
happens:

- You throw together a quick "prototype", which somehow becomes "the 
final application", and you end up having to actually "support" this thing.

- The program gets so many feature requests that the entire scope of the 
program is fundamentally altered. Sometimes a program designed for X 
ends up having to do Y instead (where X and Y aren't really related), 
but a much more common paradigm is where a program designed to do X ends 
up being required to do X, Y, Z, W, K, R, J, L, S and V. And maybe you 
could add F as well? By the weekend?

- Management think that "rapid prototyping" means "we can get away with 
one tenth of the usual development time and one hundreds of the manpower 
and still produce a working product". Uh, no, no you cannot.

> 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.

Ah yes, the source of a million bugs...

Post a reply to this message

On 11/10/2010 6:47 AM, Invisible wrote:
> http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
>
> "The old [engine] had grown to resemble the closing stages of a game of
> Jenga, in which making any change was a delicate operation that risked
> bringing the whole edifice crashing down. In particular, there were a
> dozen open bugs [...] that I had no idea how to fix."
>
> I think that's a really amusing quote. How many of you have worked on
> programs that look like "the closing stages of a game of Jenga"? :-D

I have a slew of them I have to support

They started as a very good idea that was decently cleanly coded, but 
then ad-hoc requirements and programming made them into the beast that 
they are.

I got to the point where I told my boss I could not change the programs 
any more.  We had a couple of incidents where his 'request/requirement' 
caused the program to overwrite it's own data.  Basically a couple of 
days worth of work to re-do.
Really scary - especially when the bogus data makes it out to the clients.

Post a reply to this message