From: yaniv_vi_at_yahoo.com
Date: 2001-07-30 12:05:41
hi rob
i read your mail , it's very enlightening on how to develop this
habve some remarks on the message body
thanks , yaniv
--- In buildcheapeeg_at_yahoogroups.com, "Rob Sacks" <editor_at_realization.org> wrote:
> Hi Waldemar,
>
> > Maybe if you explain in details your swplan for
> > the members, it will make the results of poll
> > more efficient. And I wonder you could help a lot
> > too in practical programming.
>
> Okay. Here's a proposal for how to write the software.
>
> My understanding is that the group wants to produce a
> fullblown neurofeedback program (something in the same
> category as Waveware, BioLex, etc.) that can be extended
> in the future to other forms of biofeedback such as skin
> temperature, skin resistance, and so forth. It will be free
> software under the General Public License.
>
> The program will work with the RS232EEG. (But with
> almost no additional effort on our part, it will also work
> with other EEG machines, so of course we should
> make it work with other machines too.)
>
> If this is correct, then here's what I think the group needs
> to do.
>
> The first step is to complete the needs analysis. I know
> you've worked on this but I'd like to suggest an entirely
> different method based on interface design. (The easiest
> way for users to contribute their ideas is by playing
> with drawings of the proposed interface.) We need
> two volunteers for this aspect of the work, one programmer
> and one user (I bet Jim Peterson would be great at
> this). Let's call these two guys "The Interface Honchos."
> Their job is to put drawings of the proposed screens for
> the new program on the Web and collect suggestions
> from everybody else. They can also publish screen shots
> of existing programs like Waveware and BioLex for
> people to react to. (One of the easiest ways to write
> a functional spec is by letting users criticize existing
> programs.)
>
> The Interface Honchos' job will be complete when they
> have drawings or screen shots of what the actual
> program will look like. All the menus and all the
> menu options will be shown in their drawings. In fact,
> this will be a functional spec in visual form. (If the
> programmer on the Interface Team is ambitious, he
> can implement the interface as a prototype in actual
> code.)
>
> Step two -- and here is what has been holding up
> the project -- is an architecture document. This
> is the blueprint that outlines the basic structure
> of the source code from the programmers' point of
> view.
>
> The architecture document describes the individual
> pieces of the program and (more important) how they
> fit together. Until that happens, nobody can write any
> of the pieces, because nobody knows how his
> individual piece will get invoked by the rest of the
> program, and nobody knows which resources in the
> rest of the program will be available to be invoked by
> his individual piece.
>
> For example, once the architecture is known, we can
> tell each programmer: "Eighteen times a second, the
> program will call a member function in your component
> called OnTick(). That will be the entry point for your
> component. If you need to find out the current FFT
> data for that eighteenth of a second, you can call
> a function in the cFFT module called CurrentData()."
> (I'm making up these details to suggest the kind of
> information that we can specify after we have a
> blueprint.)
>
> It seems to me that the most important thing about the
> architecture of this program is to guarantee that the
> source code can be easily modified in the future. The
> program almost has to be like an engine for future
> plug-ins. Ideally, if we do this right, then after the
> program is complete, a new programmer should be able to
> add a new piece to the program without changing any
> existing code. Sound impossible? It's possible, but it will
> require some clever planning at the beginning.
if we could have this -GREAT!
>
> After we agree on the architecture, we'll make a list
> of the individual pieces -- the components, which
> presumably will be implemented as C++ classes --
> and devise a schedule for writing them. The goal
> with the schedule is to be able to build a version of
> the program that runs almost from the first day. It will
> have very limited functionality, but it will run. This makes
> development much easier. (I think we should use daily
> builds, incremental development, and zero bug counts.
> That kind of stuff is a big help, and we need all the help
> we can give ourselves.)
>
> (Incidently, if anybody wants to read good books
> about the sorts of development strategies I'm outlining
> here, I recommend two books by Steve McConnell, both
> published by Microsoft Press: "Rapid Development" and
> "Software Project Survival Guide." The second book
> is intended for managers and customers, not just
> programmers, and everybody here might want to consider
> looking at it.)
>
> The next step is for each programmer to volunteer to
> write a chunk of the program. Actually, it would be great
> if each programmer plays two roles. Role number one,
> write a chunk. Role number two, review somebody else's
> chunk. That way we can do real live code reviews just
> like the big boys at Microsoft.
>
> The next step... well, that's enough for now. You'll notice
> that I didn't talk at all about ports or operating systems.
> To me, there really isn't any choice. If the group wants
> a really good-looking program, one with outstanding
> graphics and sound, it will have to be a native program
> (i.e., written directly for the OS in question), and obviously
> if we're writing for just one OS, it's going to be Windows.
> Windows implies DirectX and Microsoft Visual C++.
>
> Alternatively, we could go with the strategy suggested
> by Moritz and Joel -- portable code, multiple operating
> systems, GUI library -- but I am skeptical that we can
> achieve the same quality of graphics and sound, and the
> maintenance will be greatly complicated by the fact that
> the program will become dependent on maintenance of
> the GUI library. In general, any time you use a third-party
> library, you add a risk factor to your program, because
> new versions of the operating systems will probably break
> the library, and we'll be dependent on the library publisher
> to publish new versions quickly. If whoever wrote the
> library stops supporting it... not good.
one question how much percent is interface and how much percent is
code ?
because win98 is great but also another goal - maybe not for now ,
is portable device using palm pilot . so how hard you think it would
be to "transport" the win98 version to palm ?
also this may require palm interface design in later stage .
also maybe the s.w. should be build in a certain way for this or
there should be no problems (maybe cheking memory and speed ?)
>
> I didn't mention the port question because it's trivial
> from the software point of view. It's a hardware issue,
> not a software issue. We can add support for new
> types of ports to the program almost instantly at any
> time. At the moment, our hardware has a serial port,
> so obviously we need to write the program that way.
>
> Of the issues I raised, I think the hardest one is
> the architecture. In order to create a good architecture,
> a person usually needs to have a few years' experience
> writing whole applications. We don't seem to have a lot
> of folks here like that. Also, it's hard to do that by
> committee. In fact, I can't imagine it happening here by
> committee.
>
> The way I can imagine it happening is, somebody (let's
> call him the architect) writes a proposed design. He posts
> it. Everybody else reads it. They give criticisms, suggestions
> for changes, etc. The architect makes changes until
> everybody is happy (or too exhausted from arguing to
> argue anymore.)
>
> The biggest problem I see is that the architect is going to
> end up as the lead programmer, and not only that, he
> may end up spending a lot of time teaching other
> people about various aspects of writing software. So he
> had better have a LOT of time on his hands!
isn't there anyway to divide this work , for example - one architect ,
to write the document ,but then he explains to the experienced
people , and they pass it on ?
rob , do you think help from linux ppl should be need on managing
this ?
does anybody kno wnay linux guy ?
>
> By the way, when is Kenneth coming back? :)
>
> Regards,
>
> Rob
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:31 BST