From: Rob Sacks (editor_at_realization.org)
Date: 2001-07-30 14:00:06
Hi Yaniv,
> 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 ?
I think that could happen if we have a few programmers
with that kind of experience.
If the programmers have less experience, then it's
easier if somebody writes the core part of the
source code. Then the other programmers have
something concrete to work with. They can examine
it and add to it and modify it.
This is assuming that the other programmers like this
idea of writing an application in C++ from scratch.
I don't know if that's the case.
> rob , do you think help from linux ppl should be need
> on managing this ?
The Linux project is so big, it's probably a bureaucracy,
and I wonder if the experience would be relevant.
But I bet we could learn a lot from somebody
who had worked on a small open-source project
like ours.
Rob
----- Original Message -----
From: <yaniv_vi_at_yahoo.com>
To: <buildcheapeeg_at_yahoogroups.com>
Sent: Monday, July 30, 2001 7:05 AM
Subject: [buildcheapeeg] Re: Software development outline
> 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
>
>
>
> To unsubscribe from this group, send an email to:
> buildcheapeeg-unsubscribe_at_egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:31 BST