pcplantdb

[Richard Archer <pcplantdb@juggernaut.com.au>]

At 9:41 PM -0800 6/3/05, Stephanie Gerson wrote:

>Re: the technical spec.  It needs to get done and I don't know how.  I'll
>ask one more time - is anyone going to volunteer or do we have to 'hire'
>someone else to do it?  I'd be willing to do work (writing, whatever) as
>long as someone gives me clear direction.  But at this point, there's not
>much more I can do myself and we need to get this spec written.

At this stage the spec document does not need to be technical at all.

All it needs to do is to clearly and unambiguously state what the
goals of the project are. And it needs to do this in fairly fine
detail. I suspect that almost all the info that needs to be in
this initial spec exists in the archives to this mailing list.
But someone needs to cut-and-paste until their fingers bleed
sorting and organising the info.

One example is the thread that discussed all the attributes a
plant could have and which were useful to this project. The spec
document should list all the attributes we're going to collect
about a plant, what sort of data the attribute is and what we're
going to do with each of them. Not in a technical manner, but
generically... such as:

Root Growth Habit
- root depth
- root breadth
We will compare the root growth patterns of selected plants in
order to identify groups of plants which can grow in the same
area without competing with each other

And I think that everyone involved in the project needs to work on
this document. It can't just be delegated to one person... for a
couple of reasons:
1. It's far too much work for one person
2. Everyone can offer valuable input

Which is why I was proposing a wiki, although a bunch of small
text files in a CVS repository would do just as well.


The next stage of development is to get technical... start working out
what sort of data structures are needed and roughly outline the code
paths required to manipulate these data structures. But once the
initial spec has been written, much of the technical spec becomes
self-evident.

Jumping headlong into code-cutting on a project of this size is a
recipe for disaster. The programmer will write a bunch of code,
someone will review it and then come up with that section of the
spec document. Then the programmer has to re-write that code to
match the spec. Then the programmer writes the next bunch of code
and the reviewer writes the spec AND re-writes the spec for the
previous bunch of code. So the programmer is still at square one.

All terribly inefficient and demoralising for all concerned, and
I know first-hand how bad it can get!

I wonder if this doesn't have at least something to do with
Chad's loss of enthusiasm... he doesn't have a clear goal to
aim for and there isn't a road map of how to get there.

 ...R.