|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |