Re: Books for learning how to write "big" programs
On May 23, 3:37 am, Ian Collins <ian-n...@hotmail.com> wrote:
Martin P. Hellwig wrote:
In my opinion, bigger projects are like smaller projects
excepts you have about 90% overhead on documentation before
you even write a single line of code, of course you can try
without but that usually ends in failure of the project.
I though it was the over emphasis on paper and lack of working
code that has caused the failure of too many projects.
If all you produce is paper, I don't think that the project can
be considered a success. On the other hand, anything that
hasn't been written down and reviewed isn't there. I certainly
wouldn't go with "90% overhead on documentation"; I would argue
that any "overhead" on documentation is a sign of a poor
process. Documentation, in various formats, does appear as a
side effect of other aspects of a good process, however: you
can't do a design review unless there is a design, written down
somewhere; you can't do code review unless there is code,
written down somewhere (and the code has to be readable, which
could also be considered documentation); you can't review the
completeness of the unit tests unless there is something which
says what the unit tests test. And you're really wasting your
time if you write a single line of code without knowing why, or
what it should do---and what isn't written down, isn't known.
(That doesn't mean you need a classical external document. Just
that whatever you were thinking when you wrote the code is
written down somewhere, in some form or another.)
=46rom experience, I find that about 60% of the time in a project
will be spent in design, 30% in coding (including coding the
tests), and about 10% in debugging. But of course, it varies
greatly. And what you count in which phase may vary---if you're
using a library you're not familiar with and which isn't well
documented, you'll almost certainly end up writing some
"experiments" to see how it behaves: is that "coding", "design",
or yet something else?
I don't think that there's that much difference between big
projects and small projects in this respect. The difference
between the two is how you manage larger numbers of people on
the bigger project. In other words, not the "documentation",
but how you communicate it between developers, and how you
ensure that everyone is on the same wave length.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34