Slashdot Mirror

And at the moment, the only real way of communicating this? Comments describing the architecture.

A few years back I started incorporating UML diagrams into my design process. So before I start coding I draw out the architecture of the program, and this becomes part of the documentation. I find this useful for my own planning purposes to prevent constant refactoring, and if I need to explain the program to someone else, a picture is worth a thousand words.

"Believe it or not flowcharts and Venn diagrams are not obsolete."

Believe it or not I use mindmapping software to help plan out the structure of a program and draw relationship lines arbitrarily, I wish someone made these mindmapping programs and made them more accessable to programs and programming.

http://www.thebrain.com/

Also great flowchart drawing tools:

http://www.smartdraw.com/

http://www.smartdraw.com/ It's been around forever and you can download a free trial.

I recently finished a DB Design course and depended on Smartdraw 7. It allowed me to work much quicker then with Visio and I like it's DFD support better. You can download the eval version from http://www.smartdraw.com/.

They look kinda like Nassi-Schneiderman charts...

This goal is often achieved with a Data Flow Diagram which many people mistake for a flow chart. Structured analysis/design techniques from the 1970s and 1980s developed the DFD concept as part of the problem analysis phase. Search for the likes of Coad, Yourdon, DeMarco, Gane and Sarson. Some of these names are still familiar in the OO design world. The key differences between a DFD and a flow chart are:

• DFD does not imply sequencing of operations. Processes in a DFD can run in parallel.
• Definition of the data stores. A DFD typically includes definitions of the data stores and not simply the steps that will be taken to process the data.

In the 1980s, lots of people tried to slap object-oriented deisgn onto structured analysis using various techniques (like making the processes or data stores the objects). It didn't work out so well. Eventually, we got to UML from there after 10-15 years of haggling and stumbling; some argue that it still isn't working out so well.

• contractor punch lists
• P.E.R.T. charts
• A replacement for Microsoft Project
• Emergency notification call list trees
• Web site content change propagation update tool
• Human Resource function support (Did Bill, tell his department? How about Sue? ... )
• Legal case tracking
• And of course, nachos :-)

We're releasing the code under a BSD (no advertising) license.

Great.
It may cost you the easy use of some GPL stuff, but for a project where it is unlikely that anyone will clone it, close the source, and sell it for a profit without sharing the source, the whole "duty to the future" argument of the GPL goes away. If there is something you desperately need, you still have the option of contacting the author of the library or tool in question and asking if they'd release it LGPL so you could provide the source at your website, link to it with the BSD licensed code, and the BSD code would not be in any way derivative.

We could put together a kick-ass demo, but it would stall the project.

Though I would agree that it disrupts your workflow and that this costs you time (and brainbandwidth) I would simultaneously argue that the time cost of getting two scenes "demoable" will be at least 50% recouped because you'll actually be doing work that would have had to occur down the road anyway.

The three primary benefits that I can see are:
a) It tests some of the worrisome assumptions. You may assume that you can easily layer sound effects over background music, but until you try, you don't know whether the library does this worth a damn. You may have addressed this issue, but I've little doubt that this early on in your development that there are some scary assumptions that a demo could help put to rest.
b) If it gains you 1 good, 3 average, and 5 mediocre, developers, I think you'll recoup the time cost shortly.
c) It tests some of your time assumptions regarding how long it takes to do things. If you want to break the project down into work-units it will help to have unbiased people of known skill-levels setting the standard.

...suggestion, to publicly post the TODO list... The problem is that it is very hard...

Yup.

...to have it done piecemeal.

I agree whole heartedly that there are some chunks that need to be kept in tight groups and done by a core team, but those people's work can still be broken down into work-units to credit them for their contribution and rank them for a prize. I was picturing something like a Gantt chart, like this.
Parallel tasks are vertically adjacent, dependent tasks are to the right of their dependency.

The scale right to left can be 5 pixels = 1 work unit. A system like this lets you shade the tasks in increments and tells people quite a few things like, "When will they be ready for animation artists?", "When will they need my expertise in graphical installers?"

Starting with the T-Shirts is a great plan. Use local talent if you can for that. The fact is, printed T-shirts are often significantly marked up. If you found your local T-shirt printer was sympathetic to your cause and wanted his company name on your list of supporters he might get them to you at cost (setup, transfer stuff, plus ~$5 per T). Have your graphic people figure out what might look good in two colors (T color, plus print color), as those simple silkscreenings can very cheap to do (very small cost for transfers.

...it would be very easy for one person to end up with 4 Video cards.

My initial idea was that the prizes would go out at the "completion party" and it would be one prize per person.

At 730 Units Bob gets a vid card
At 535 Units Randy gets a vid card
At 434 Units Carol gets a vid card
At 410 Units Harold gets a vid card
At 320 Units Thelma gets a sound card
...
etc.

This way your top 12 volunteers all walk away with (one apiece) a cool bit of hardware.

You could spread it out differently though. If your milestones spaced out to make a little more income available at the first third of the project completion, your top twelve c