Warp wrote:
>   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,

Yes, this exactly.

And worse, the request comes from a customer who "will buy it if we put this 
in."  But it takes three weeks to put it in, and the customer waits 2 weeks 
and changes their mind, because the customer didn't really want to buy it 
anyway but didn't want to tell the pushy salesman to go stuff it.

So you not only have a whole bunch of bags on the side (which is the old 
timer's name for such features), but you have a whole bunch of bags half of 
which are leaking.

I can't even say how many projects I've worked on that weren't even spec'ed 
out enough for the person asking for the project to realize it's impossible 
to implement.  Stuff like sample reports with amounts and totals marked as 
"$XXX.XX" in the example, with calculations that mean the grand total at the 
bottom right can't be both the sum of the column above and the sum of the 
row to the left.

>   Thus the project advances. What started as a small, lean&clean prototype,
> with nice little modules and functions, starts slowly but steadily growing,

I *did* work in one place briefly once, where each project timeline would be 
estimated based on "is this a one-off, or a production system? Are you 
asking this question once, or will you ask again."  Asking once might take a 
week to code, while asking in production would take six to eight weeks.

The cool thing was, after the one-off, you ran the program, took it to the 
person that asked for it, and if they approved, you got them to sign off on 
the timesheet. Then you went back and deleted the code.

When they come back the next month and say "I need that report again", you 
get to say "It'll take a week this time also."

That was back when managers didn't think they could dictate development times.

Nowadays, where I work, nobody even starts writing the spec until after 
they've decided when the feature will be released. I kid you not.


Only occasionally have I managed to convince a boss it'll be faster to 
rewrite this from scratch than it will be to add the feature you're asking for.

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

Post a reply to this message

On 11/10/2010 8:39 AM, Mike Raiford wrote:
> 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.

Curse you!  I was going to say that!

Regards,
John

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

If you don't manage a project properly, anything non-trivial can turn 
into that.

I suppose project managers should remember that whenever the 
requirements change, the project goes back to square one.  And they 
should promise accordingly.  And their bosses should accept this.

Regards,
John

Post a reply to this message

On 10/11/2010 07:36 PM, Darren New wrote:

> That was back when managers didn't think they could dictate development
> times.

This is probably reason #1 why software projects fail.

Today it seems that management think that working out how long something 
will take is as simple as plucking a number of out thin air. This leads 
directly to absurdities such as...

> Nowadays, where I work, nobody even starts writing the spec until after
> they've decided when the feature will be released. I kid you not.
>
> Only occasionally have I managed to convince a boss it'll be faster to
> rewrite this from scratch than it will be to add the feature you're
> asking for.

QED.

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
>
> If you don't manage a project properly, anything non-trivial can turn
> into that.
>
> I suppose project managers should remember that whenever the
> requirements change, the project goes back to square one. And they
> should promise accordingly. And their bosses should accept this.

Amen!

Interestingly though, the project being referred to here is an open 
source system that (AFAIK) nobody even gets paid to work on. So while 
it's legendary that commercial applications end up looking like 
spaghetti soup due to ridiculous specs, absurd deadlines or the 
employment is incompetent programmers, none of those would seem to apply 
here. So how does an open source project end up like this?

Well, I can think of a couple of reasons:

- There are approximately 3 active developers (with a larger cloud of 
occasional contributors floating around the outside). I don't think 
there's anybody really "in charge" of "project managing" the thing as 
such, development just kind of "happens". And there's always a task list 
the size of a small moon, with nowhere near enough people to attack it.

- This isn't some enterprisy system that just pushes data around in a 
database. This is a compiler. It involves serious heavy-metal logic 
theory and so forth, which is quite easy to get wrong.

- It has /a lot/ of "experimental" features. The design of these can and 
does change from time to time.

The "game of Jenga" they just replaced wasn't just a case of deleting 
the code and rewriting it from scratch. Rather, a couple of PhDs spent 
about 3 years designing a consistent logical theory for how all the 
features should work. Actually /implementing/ this was the easy part.

It seems likely that this is an activity which will only get repeated in 
the future...

Post a reply to this message

On 11/10/2010 7:44 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.
>
> My God have mercy on your soul.

I'm beginning to wonder if I've died and gone to Hell...

-- 
~Mike

Post a reply to this message

On 11/10/2010 8:21 AM, nemesis 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...
>

In our case I think it's a matter of requirements drift and feature 
creep making it so fragile. We've done so many "pull this block out and 
place it in a different area of the stack" changes lately, that the 
software really is starting to resemble Jenga.

-- 
~Mike

Post a reply to this message

On 11/10/2010 10:03 AM, Darren New wrote:

> off of managing, and have employees who are decent coders but shit
> programmers, and still think you can create something usable. Which

I'm curious. What is the distinction between a coder and programmer, here?

-- 
~Mike

Post a reply to this message

On 11/10/2010 10:52 AM, Invisible wrote:

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

Oh, yes.. and while you're at it, would it be too difficult to add ∂, ∆, 
σ, λ, θ, ω? I really thing feature ω will be the ultimate feature for 
this application!

-- 
~Mike

Post a reply to this message

>> - 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?
>
> Oh, yes.. and while you're at it, would it be too difficult to add ∂, ∆,
> σ, λ, θ, ω? I really thing feature ω will be the ultimate feature for
> this application!

Sure. Just for the love of God, don't ask me to make it a web 
application and expect it to work in IE /and/ standards-compliant 
browsers... >_<

Post a reply to this message