Timeless Classics of Software Engineering

[Gene Wirchenko]

[snip]

Right. That was a knee-jerk reaction to UML book somebody nominated.
Database people would easily trade a stack of UML books to a decent database
text.

Not true at all. I am keeping my UML text as an example of how
horrible a textbook can be. It was not all bad though, just the part
dealing with UML. The C++ portion was OK. Two authors, two areas,
one suspicion on my part.

P.S. Thank's god nobody mentioned "Learning XML in 21 minutes" by Bill
Quickbuck yet.

And it only *seems* like 21 days?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

 

[Marshall Spight]

No database textbooks listed so far. Is it because
1. There are no classic database books.
Or rather
2. Software engineers usually don't know anything about databases.
?

Or both.


Marshall

 

[Peter Amey]

Andi Kleen wrote:
[snip]

I always liked "Debugging C" from Robert Ward.

What /is/ this "Debugging" of which you earth people speak?

Oh, Debugging /C/ - now I understand.



Peter

 

[Rob Warnock]

+---------------
| DeMarco has quite a number of good books on the topic, but his "The
| Deadline" is by far the most entertaining, most fun, and most on-target
| book I've read on the subject of what makes a project tick.
+---------------

My favorite Tom DeMarco book is "Controlling Software
Projects: Management, Measurement, and Estimatation".
The first chapter starts out with the classic reminder:
"You can't control what you can't measure."


-Rob

 

[Alfredo Novoa]

No database textbooks listed so far.

And some of the books listed promote the worst data management
practices like to manage the data in the applications using network
structures and procedural code.

Is it because
1. There are no classic database books.

Clearly false.

Or rather
2. Software engineers usually don't know anything about databases.
?

If you read the classic software engineering textbooks you will see
that this is very true.

Database theory is essential to build decent business information
systems, and you will find almost nothing about databases in the
software engineering books.

It is not surprising that most business systems are a botch-up.


Regards

 

[Jerry Coffin]

[ ... ]

No database textbooks listed so far. Is it because
1. There are no classic database books.
Or rather
2. Software engineers usually don't know anything about databases.

I would say:

3. Because the OP asked about SE, not databases.

I, for one, can think of at least a couple I'd consider classics about
database design, just as I can think of some I'd consider classics
about compilers, operating systems, networking, etc.

A few might qualify as crossovers as well: just for example, Lion's
book or almost any of Tannenbaum's books could be used for studying
SE, with operating sytsems as the example code. Likewise, the Dragon
Book could be used as a study in SE with compilers as the sample code.

Likewise, almost anything by C.J. Date or E.F. Codd could qualify as a
more or less timeless classic, but none of them is more than
tangentially related to SE.

OTOH, I'd say Robert Heinlein or F. Paul Wilson might have just as
relevant of messages for software engineers as Date or Codd...

 

[--CELKO--]

I'd like to hear thoughts on what books, in your opinion, are true
classics in the field of software engineering. <<

"Classics in Software Engineering" and "Writings of the Revolution" by
Edward Yourdon, both now Out of Print. They are a good collection of
all the basic essays and short papers that lead to Software
Engineering and structured programming in the early days.

 

[Jerry Coffin]

(e-mail address removed) (Steve Johnson) wrote in message
[ ... ]

Are there any other books like MMM that you can think of where every
page is packed with insight where it seems not a single word is in
vain?

_Programming Proverbs_ by Henry Ledgard.

This does have some shortcomings: first of all, it's probably been out
of print for at least 20 years, so if you get it at all it'll probably
be used. Second, the sample code is all in languages most people would
consider obsolete, such as PL/I and FORTRAN IV. Finally, it came along
when top-down programming was a new and wonderful thing, and the
author might be considered bigoted on the subject (his third and
fourth proverbs are "Use the top-down approach" and "Avoid other
approaches"). Nonetheless, I think it's better than most of the more
recent attempts I've seen at the same genre.

 

[Andi Kleen]

No database textbooks listed so far. Is it because
1. There are no classic database books.

Gray/Reuter - Transaction processing: concepts and techniques

is probably one. It doesn't focus much on high level database theory,
but more on practical implementation of one (down to code samples).

And it is useful for a lot more things than just databases. I
found it useful to understand journaling file systems.

-Andi

 

[Mikito Harakiri]

3. Because the OP asked about SE, not databases.

I, for one, can think of at least a couple I'd consider classics about
database design, just as I can think of some I'd consider classics
about compilers, operating systems, networking, etc.

Agreed. However, there was little point crossposting to c.d.t.

 

[osmium]

OTOH, I'd say Robert Heinlein or F. Paul Wilson might have just as
relevant of messages for software engineers as Date or Codd...

And Heinlein is listed in the end notes of Brook's book. The circle is now
complete!

It occurs to me that the OP's best bet is to put <brooks mythical> as a
taget to Google. This will work to find things that Brooks found useful and
any one later is almost certain to reference back to Brook's. Personally,
as an electrical engineer, I have difficulty with this notion of what
software engineering is. My take is that the vast majority of the responses
have not been what the OP wanted. But I can't figure out *what* he really
wants from a single example. I have Brook's book, but have never actually
read it, just scanned it. I view it as a "war stories" kind of thing.
That's not meant to be critical in any way.

The subject most of the answers seem to address is: good books for
programmers. Either classics, or "gonna be" classics. The OPs mention of
Knuth makes clear that is not what he wanted.

ISTM that Cormen, _Introduction to Algorithms_ belongs on the list that is
actually being generated.

 

[Tony Nelson]

...Likewise, the Dragon
Book could be used as a study in SE with compilers as the sample code.

That book is far more popular than it deserves to be. The authors have
a positive talent for making obscure exposition seem meaningful, without
covering the necessary material, while making what they cover more
complicated than it really is.
____________________________________________________________________
TonyN.:' (e-mail address removed)
'

 

[Andi Kleen]

That book is far more popular than it deserves to be. The authors have
a positive talent for making obscure exposition seem meaningful, without
covering the necessary material, while making what they cover more
complicated than it really is.

The first chapter of the Dragon Book is not that bad as an introduction.
But if you look for a true classic on compiler writing check Wirth's
Compilerbau. 120 pages only and it covers everything you need
to write a quite usable compiler.

-Andi

 

[Christopher Browne]

Clinging to sanity, (e-mail address removed) (Jerry Coffin) mumbled into her beard:

A few might qualify as crossovers as well: just for example, Lion's
book or almost any of Tannenbaum's books could be used for studying
SE, with operating sytsems as the example code. Likewise, the Dragon
Book could be used as a study in SE with compilers as the sample
code.

There's a bit of a problem with that; when SE's are expected to build
systems that involve database usage, and they _don't_ have any
guidance as to why databases should be used one way or another, it's
pretty likely that they will re-invent the same _broken_ wheels that
others have repetitively invented over the years...

Substitute
s/database/compiler/g
s/database/linker/g
s/database/markup language/g
as needed...
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/linuxxian.html
Rules of the Evil Overlord #24. "I will maintain a realistic
assessment of my strengths and weaknesses. Even though this takes some
of the fun out of the job, at least I will never utter the line "No,
this cannot be! I AM INVINCIBLE!!!" (After that, death is usually
instantaneous.)" <http://www.eviloverlord.com/>

 

[Gene Wirchenko]

[ ... ]

No database textbooks listed so far. Is it because
1. There are no classic database books.
Or rather
2. Software engineers usually don't know anything about databases.

I would say:

3. Because the OP asked about SE, not databases.

Oh, sure, spoil it by staying on-topic.

I, for one, can think of at least a couple I'd consider classics about
database design, just as I can think of some I'd consider classics
about compilers, operating systems, networking, etc.

A few might qualify as crossovers as well: just for example, Lion's
book or almost any of Tannenbaum's books could be used for studying
SE, with operating sytsems as the example code. Likewise, the Dragon
Book could be used as a study in SE with compilers as the sample code.

Likewise, almost anything by C.J. Date or E.F. Codd could qualify as a
more or less timeless classic, but none of them is more than
tangentially related to SE.
Agreed.

OTOH, I'd say Robert Heinlein or F. Paul Wilson might have just as
relevant of messages for software engineers as Date or Codd...

How about Robert A. (Anton) Wilson? <EG>

Fnord.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

 

[Eray Ozkural exa]

That book is far more popular than it deserves to be. The authors have
a positive talent for making obscure exposition seem meaningful, without
covering the necessary material, while making what they cover more
complicated than it really is.

Well, the dragon book isn't bad, but I think a compiler book which
covers more recent developments would be needed.

I think compilers have changed a lot since 70s. For instance, the book
doesn't cover how to design a compiler for a parallel programming
language (not that we know how to, but it should be emphasized that
program representation must contain information suited to our goals).
There are also a lot of parser generators nowadays that go beyond what
is discussed in the book. If anybody wants to write a C++ parser, the
book will be only marginally useful... I'm also thinking of the
wonderful combinatorial categorial parsers and the like, these can be
used for artificial languages. For instance, I've found the Parsec
parser library for Haskell to be a wonderful programming exercise.

Best Regards,

 

[Nick Landsberg]

Clinging to sanity, (e-mail address removed) (Jerry Coffin) mumbled into her beard:



There's a bit of a problem with that; when SE's are expected to build
systems that involve database usage, and they _don't_ have any
guidance as to why databases should be used one way or another, it's
pretty likely that they will re-invent the same _broken_ wheels that
others have repetitively invented over the years...

Substitute
s/database/compiler/g
s/database/linker/g
s/database/markup language/g
as needed...

Amen to that, Chris.

It seems there's a normal human attitude that
"the other guy's job is easier," so we tend to
underestimate the effort involved in those
areas where we don't have expertise. Or, more
precisely, we underestimate the level of experience needed
to be reasonably adroit with a certain
"thing" (database/compiler/linker, to use your
examples).

 

[Alfredo Novoa]

It seems there's a normal human attitude that
"the other guy's job is easier," so we tend to
underestimate the effort involved in those
areas where we don't have expertise.

The problem with the Information Technology camp is that most
practicioners have not expertise in Information Technology, but only
in isolated parcels.

Or, more
precisely, we underestimate the level of experience needed
to be reasonably adroit with a certain
"thing" (database/compiler/linker, to use your
examples).

Most software developers and engineers underestimate the level of
knowledge about databases needed to be a reasonabily compentent IT
professional. (But I am trying to cease to be among them


Regards
Alfredo

 

[Gene Wirchenko]

[snip]

It seems there's a normal human attitude that
"the other guy's job is easier," so we tend to
underestimate the effort involved in those
areas where we don't have expertise. Or, more
precisely, we underestimate the level of experience needed
to be reasonably adroit with a certain
"thing" (database/compiler/linker, to use your
examples).

I think this is because one can easily understand the high-level,
abstract description (or executive summary) of what has to be done.
If one makes the mistake of thinking that that is all there is to the
work, one gets the above effect. The same mistake is not made in an
area that one is proficient in, because one knows about the
difficulties.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

 

[Nick Landsberg]

[snip]

It seems there's a normal human attitude that
"the other guy's job is easier," so we tend to
underestimate the effort involved in those
areas where we don't have expertise. Or, more
precisely, we underestimate the level of experience needed
to be reasonably adroit with a certain
"thing" (database/compiler/linker, to use your
examples).

I think this is because one can easily understand the high-level,
abstract description (or executive summary) of what has to be done.
If one makes the mistake of thinking that that is all there is to the
work, one gets the above effect. The same mistake is not made in an
area that one is proficient in, because one knows about the
difficulties.

Sincerely,

Gene Wirchenko

Good point, Gene.

The corollary to your observation would be that since
management only ever reads executive summaries, they
presume all tasks are relatively trivial and can be
outsourced.

(But that's a subject for a different thread and which has
been rehashed many times over in various newsgroups.)

NPL