Meeting

[abez]

I find this strategy works well. Write docs for your code before hand. Specify
how you want it used. Don't spend too much time on it.

Write it.

Reverse Engineer your new code and see what has changed, update your docs or
make new ones.

I think doxygen works for perl now..

Before you release anything in the wild you should provide some docs otherwise
people won't use it and if people won't use it why release it?

On Thu, 12 Dec 2002, Darren Duncan wrote:

> Funny that you should bring this up.  While not exactly the same thing, I
> was planning to write the *documentation*/specification for my new RDBMS
> module before writing the code, since it is new enough that I don't know
> entirely what it should do yet.  Writing documentation first would help to
> solidify this, and allow people to comment on the spec prior to committing
> anything to code.  In fact, I would probably make my first upload to CPAN
> in that form, perhaps as version zero; the next release, version 0.01
> would have some code, which is enough to do something useful (what my app
> is currently using).  Or should the docs-only first release be 0.01?  I
> wasn't going to start writing tests immediately for this module, but if
> our meeting shows me how to do it quickly/easily then I just might do it
> from the start after all.
>
> -- Darren Duncan
>
> P.S. This is my current idea for a DSLIP.  The 'a'lpha status recognizes
> the early release that, while the code works, it may be subject to heavy
> changes so one shoudn't count on the interface staying unchanged.
>
> Name-------------- DSLIP 12345678901234567890123456789012345678901234 Author-
> DBIx::
> ::Portable         adpOp Framework for RDBMS-generic apps and schemas DUNCAND
>

-- 
abez----- ----- ------ - ------ -- ------------
http://www.abez.ca/ Abram Hindle (abez at abez.ca)
--- --- ------ --------- - - ------ --------abez