From: Rob Sacks (editor_at_realization.org)
Date: 2001-07-29 13:31:41
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.
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.
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!
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