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