> BTW, while I'm very much in favour of having FlightGear's various > subsystems split into distinct parts, I think the "bad design" claim > coming from you is pretty weak. Where was your voice when the Local > Weather subsystem was added ?
Gentlemen, it's so nice to be mentioned so often if an example for bad design is needed :-) I don't really understand what you'd see as 'good design' in this instance, but I can tell you why it is the way it is, and maybe there's a useful lesson for the future in there. Local Weather started out of my experiments with how to render various cloud types, initially using the AI system, which was a problem I found quite interesting in itself. At some point, Hooray in the forum pointed out that what Flightgear could use was an integrated weather system. I thought about that problem over night, had the impression that I could do it and designed a system. The first thing I did was setting up a wiki page sketching the project. The second thing was asking for comments, ideas and help. I'm pretty sure at this point most people thought 'That's never going to be finished anyway.', smiled and turned away (can't really blame anyone). So most of the time I discussed with Hooray (and a few glider enthusiasts), that's why most of the structure that isn't my design is based on his ideas how things should be (and he's a Nasal enthusiast). At this point, it made a lot of sense to code in Nasal, if only for the simple reason that I couldn't know if it would ever included into the base package or not. A Nasal-coded addon you can distribute with reasonable effort - a C++ patch which people have to recompile reaches a far smaller target audience. Serious contact with core developers (a big thanks to a lot of people here who worked with me on various aspects of the system at this point!) didn't happen until much later when the structure of 'Local Weather' as an optional addon which is off by default was largely fixed. What could have changed this is not project management - if someone would have told me 'You must code this in this structure, and we need it like that' I'd have said 'Can't do it - don't understand the requirement.' and wouldn't have done anything. The thing that could have made a difference is a kind of tutoring system - someone working with me, explaining to me what design works in what way and helping me code what I can't code (I come from scientific computing - which means I usually write codes for a single user (me) with zero requirements on integrating into bigger systems, GUI,... and largely performance and accuracy being the goals - so I can work out what methematical function describes cloud distributions easily, but I can't know what design is superior to what other design). > FlightGear is a huge, complex project and has no kind of real project > management at all. Doesn't mean it's bound to be a failure though... Consider the ATLAS particle detector at CERN, one of the most amazing pieces of technology on this planet. The ATLAS collaboration involves several thousand physicists, and it has a spokesperson (not a leader), because (freedom of research, the collaboration members bring their own funding) nobody is really in the position to command another sufficiently senior person. For the juniors, there are dual hierarchies, collaboration and local institution, so a single PhD student can have two superiors telling him to do two different things. The collaboration is run my a messy exercise of finding any sort of consensus - people have to talk to each other to arrange things and convince others of their view, if they fail to do so, several groups may be working on the same analysis at the same time. For instance, muon chambers are built with some set of specifications - but are all different in details, so dependent on which institution built them, the readout software needs several different option just to accomodate what kind of chamber this is precisely. I bet no company would ever consider this messy, anarchic process of common consensus-finding and pulling into different directions as a form of sane project management - and yet, it works! The anarchic club of ingenious trouble-making physicists has built a machine which no company could hope to develop. Flightgear has a lot less trouble finding consensus, because the numbers are much smaller than in the ATLAS collaboration. I think just talking, tossing ideas around, exploring detours, merge things in later can be a very efficient approach. It may lack the elegance of managed projects - but it can produce things which are out of reach of managed projects. Just my two cents. * Thorsten ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
