«

Hi:
I would like recommendations for books (in any language, not
necessarily C++, C, python) which have walkthroughs for developing
a big software project ? So starting from inception, problem
definition, design, coding and final delivery on a single theme
or application.

Most of the code I have written and books that I have read deal with
toy programs and I am looking for something a bit more
comprehensive. For example, maybe a complete compiler written in C++
for some language, or a complete web server or implementing
..net libraries in some language (just a few examples of the scale of
things I am interested in learning).

Thanks!
Duli.

duli wrote:
> Hi:
> I would like recommendations for books (in any language, not
> necessarily C++, C, python) which have walkthroughs for developing
> a big software project ? So starting from inception, problem
> definition, design, coding and final delivery on a single theme
> or application.
>
> Most of the code I have written and books that I have read deal with
> toy programs and I am looking for something a bit more
> comprehensive. For example, maybe a complete compiler written in C++
> for some language, or a complete web server or implementing
> .net libraries in some language (just a few examples of the scale of
> things I am interested in learning).
>
> Thanks!
> Duli.
>
>

Hmm I think it has not so much to do with the programming language or
the complexity itself. Might be a good thing to look for stuff like
project management, Release Management and Software Life Cycle.

A good starting point might be this:
http://en.wikipedia.org/wiki/Softwar...opment_process

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.

--
mph

On May 22, 1:23*pm, "Martin P. Hellwig" <x...@xs4all.nl> wrote:
[snip]
> 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.

With the caution that the small-big division here should be
round about the size of project that you can do in one day,
and can hold the entire spec in your head without notes.

And that the percentage may not be quite as high as 90%.
But it should be well over half. Actual coding on most
complicated commercial projects isn't usually as much as
50 percent of the total effort. And the larger the app,
the more time you need to spend in docs, design, testing,
verification, and other such issues.

As several of my bosses have stated: The job is not over
till the paperwork is done.

There are a few language specific issues for large apps.
Probably you can get most of the benefit from such books
as _Effective C++_ and the other books by Scott Meyers
in the Effective line. Don't forget to look for the CD
version of the first two books.

Also, I see that John Lakos seems to have updated his book.

Large-Scale C++ Software Development by John S. Lakos
(Paperback - Mar 28 2009)

But it does not seem to be possible to order it from
Amazon as yet. I don't know if this is just the old
text (which lost stars in reviews due to being dated)
or a new text with updated coverage.
Socks

On May 22, 10:55*am, duli <dulipi...@gmail.com> wrote:
> Hi:
> I would like recommendations for books (in any language, not
> necessarily C++, C, python) which have walkthroughs for developing
> a big software project ? So starting from inception, problem
> definition, design, coding and final delivery on a single theme
> or application.
>
> Most of the code I have written and books that I have read deal with
> toy programs and I am looking for something a bit more
> comprehensive. *For example, maybe a complete compiler written in C++
> for some language, or a complete web server or implementing
> .net libraries in some language (just a few examples of the scale of
> things I am interested in learning).
>
> Thanks!
> Duli.

The "Programming Python 3rd Ed." by Lutz has a fairly extensive email
program both as a CLI and a GUI (Tkinter) program. He has various
other real programs too, but they're much smaller.

Other than that, I'd recommend joining a project programmed in Python.
Search SoureForge for them...

Mike

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.

--
Ian Collins.

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.)

From 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:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:

> 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.

This might be true for some projects but certainly not in the general
case -- sometimes, the goals to achieve are somewhat blurred or might
not yet be known in entirety and have yet to be discovered. In such
situations, explorative programming is (imho) more effective than trying
to pen it down on paper beforehand.

Matthias Buelow wrote:
> James Kanze wrote:
>
>> 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.
>
> This might be true for some projects but certainly not in the general
> case -- sometimes, the goals to achieve are somewhat blurred or might
> not yet be known in entirety and have yet to be discovered. In such
> situations, explorative programming is (imho) more effective than trying
> to pen it down on paper beforehand.

Indeed. I'm just embarking on that voyage of discovery with my current
client. With eight stakeholders, all with slightly different and
somewhat vague ideas what they want, it should be an interesting journey.

--
Ian Collins.

On May 22, 5:55*pm, duli <dulipi...@gmail.com> wrote:
> Hi:
> I would like recommendations for books (in any language, not
> necessarily C++, C, python) which have walkthroughs for developing
> a big software project ? So starting from inception, problem
> definition, design, coding and final delivery on a single theme
> or application.

Take any Python Web framework, study the source and ask questions.
Also, keep reading this newsgroup, there are plenty of discussions
about (good) design practices.

Michele Simionato

On 23 mai, 10:36, Matthias Buelow <m...@incubus.de> wrote:
> James Kanze wrote:
> > 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.

> This might be true for some projects but certainly not in the
> general case -- sometimes, the goals to achieve are somewhat
> blurred or might not yet be known in entirety and have yet to
> be discovered. In such situations, explorative programming is
> (imho) more effective than trying to pen it down on paper
> beforehand.

Yes, but you still have to decide what you're exploring. You
don't just write random code; you write code to fulfill some
specific specification. Whether you're sure that it's the right
specification or not is separate issue---in practice, I'd say
that it's even more important to document what the code is doing
if you're not sure about the specification.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34