Re: First class developer: who ?
Martin Gregorie wrote:
(2) If the task will take a few days, such as writing a non-trivial Java
library class, say for parsing or writing CSV files, My design document
is often written as an overall description of the classes purpose,
functionality and processing options followed by API definitions and
associated textual descriptions of their intended use. When I'm happy
that the requirement is complete and doable I can turn it into a class
file by making text into comments and APIs into method interfaces, add a
few curly brackets and return statements and have something that is
immediately compilable. Then I can generate javadocs to see if they are
readable and tweak the text to suit. After that I can write a test
harness, test scripts and add code into the skeleton. Just as Lew
probably does, I'll often do these three in parallel but with carefully
compartmentalised thought processes: its *much* better to write the test
script(s) and add the call to the test harness before actually coding the
content of any particular method. Additionally, you can start regression
testing long before the coding is complete.
Place a ruler on your two extended index fingers. From in front of you, it
looks like this:
__________
O O
where the little circles represent the view of the tips of your index fingers,
and the line represents the ruler seen edge-on.
Only your two extended index fingers support the ruler.
Now slowly move your two fingers toward each other without otherwise touching
the ruler:
__________
O O
--> <--
As your fingers move together, the ruler will wobble and regain balance
repeatedly until your fingers meet.
Your fingers will meet at the exact center. As they move, the ruler's
friction will catch sometimes on the left index finger, letting the right one
progress, and sometimes on the right index finger, letting the left one move.
It's a dynamic balance that alternates movement until it meets at the
perfect center.
In software development, you go back and forth between the "left index finger"
of planning and the "right index finger" of implementation. If you follow the
correct process, some of one, then some of the other, it will converge on the
exact balance point between the two.
In my new project, I had to spend the first week putting together a sample of
the example of the proposed prototype, since the client has no specification.
This creates a working, deployable framework, upon which I can hang any
reasonable interpretation of the project's goals. There's a working database,
screens can navigate to each other, the program can access the database,
there's a mechanism in place to control the look and feel easily, but we still
don't know exactly what we want to the program to do.
Coming into the second week, I have be careful lest the client expect me to
somehow magically produce exactly the thing they imagine, even though they
have yet actually to imagine it.
That means, as architect, designer, implementer and chief bottle-washer for
this proposed prototype, I must now gently and compassionately guide the
client to reveal their hopes and dreams, and I must be the documenter, too,
writing down and editing their fantasies to realizable specifications.
Oh, yes, editing. But every change, clarification and requirement will be
provably and beyond suspicion the client's idea.
--
Lew
"Trust me, later you'll thank me for this."
Adrian Monk, /Monk/ USA Network