Re: Quick question... Is this project dead?!

On Mon, Jan 17, 2005 at 09:19:23PM +0200, Kimmo Sundqvist wrote:
> Either way, do "we" or whoever will take the lead, know what he is doing?

What's perhaps more interesting is "do the current project leads know
what they're doing?" Despite the potentially inflamatory nature of this
statement, I think most people overlook that it's one thing to be able
to manage yourself, it's quite another to manage a team of localised
programmers and it's another thing entirely to manager a de-localised
group of programmers/users effectively when you have virtually no free
time yourself.

Most people *want to be managed*. They want someone to say "go and
refactor this bit of code", "go and extend this API to provide this
functionality". It can be quite effective to do that it you have some
idea of what amount of time other people can put in and if you trust the
quality of the code that they'll produce. Both of these requirements
kinda fly out the window with people you don't know and will probably
never meet.

Putting the code up there and just shouting "develop" doesn't seem to
be very effective. Not that I'm saying this has happened mind, but
without some kind of regular statement from the leaders, the atmosphere
tends to degenerate in that way - of course, it's pointless having
statements from the leaders when there's nothing to report.
Catch-22, ish.

This is purely a guess, but I think this is the first (only?) such
project that Mark has managed. I really don't envy him. For my own such
projects I tend to lock up documentation, code and mailing lists to
avoid the project being murdered by slashdot. I /invite/ developers to
join me, try to get some kind of commitment from them in terms of what
they will or won't do and damn it all, I'm still a student - I can
happily burn 20 hours a week working on my own projects. Now whilst this
is all possible when you don't have to earn your food and can meet people
in person and have a chat down the pub, it's a lot harder over the net.
None of us do courses in "distributed development organisation and
project management".[0] What, in the pub, is a 10 minute chat explaining
the architecture of a particular piece of software becomes about 5 hours
of graphics and html work to get the same thing done on a website.

So, in short, it's really hard, and as far as I know, Mark and Phil and
others aren't particularly experienced at it. (yes, I know Andrew, you're
different)

> I think there was also something in Mark's original design that got some 
> rethinking after this "first try", but I just can't put my finger on what 
> exactly was it.

Nothing goes right the first time you write it. This *should*[1] be
intentional. A *large* amount of any project development time should be
spent on refactoring. You do the simplest thing that could possibly work
and get it out the door. Then, refactor as necessary. Note the
difference between the simplest thing and the easiest thing.

To be honest, I would expect project management to happen in the same
way: it won't go right the first time. People make mistakes and things
happen that would best be avoided. I suspect Mark regrets Y making it
onto slashdot twice and I know from personal experience that it's
*never* a good idea to make noises about "expected" development
timetable (though I don't think I've seen any of those here).

If you want to do something with Y then go and do it. If you don't have
enough understanding of what Y should be (which is entirely subjective)
or you're not up to being a project lead, or you're not a good enough
coder then you have a choice:
a) solve those deficiencies or b) shut up. Moaning about lack of
progress when you're not in a position to make progress yourself is
not effective. This isn't aimed at anyone in particular - I do not
presume to know what you are and aren't capable of. If you're really
feeling up to it then reimplement the whole thing from scratch: it's not
a lot of code really.

Matthew
-- 
Matthew Sackman

[0] There are very few people qualified to teach it, though of course,
    they'd manage to dig up some plonka to deliver a truely dreadful
    course.
[1] Well, assuming you prescribe to the scrum and/or XP development
    methodologies.

BOFH excuse #108:
The air conditioning water supply pipe ruptured over the machine room