Software Engineering Reading List
Software Engineering Reading List
Software Engineering Reading List
Construction Practices
Buy the book A Code Complete, Steve McConnell
Buy the book A Programming Pearls, Jon Bentley
Buy the book - Practice of Programming, Brian Kernighan and Rob Pike
Buy the book - Writing Solid Code, Steve Maguire
Buy the Book - Programming on Purpose: Essays on Software Design, P. J. Plauger
Buy the book - Programmers at Work, Susan Lammers
Professional Ethics
Get the code A Software Engineering Code of Ethics and Professional Practice, ACM/IEEE-CS
Periodicals
Subscribe - Software Development
Subscribe - IEEE Software
Algorithms
Introduction to Algorithms, Thomas H. Cormen, et al. This comprehensive book contains an exhaustive
discussion of specific algorithms, algorithm analysis, and algorithm design (though not as exhaustive as Knuth's
seven volume series).
Data Structures and Algorithms, Aho, Hopcraft, and Ullman. This book is focused as a textbook introduction to
data structures. It contains excellent discussions of arrays, records, pointers, lists, and trees. It also covers the
fundamental algorithmic topics of searching and sorting.
Algorithms in C++, Robert Sedgewick. This is a good choice if you want a book whose examples are in C++.
The Art of Computer Programming, Donald Knuth. These are the touch stone books in the field, though they
certainly are not light reading. These are the first three volumes of a series that was originally intended to be seven
volumes. They can be somewhat intimidating. Aside from the English description of the algorithms, they're
described in mathematical notation or MIX, an assembly language for the imaginary MIX computer. Nevertheless,
they contain exhaustive details on a huge number of topics, and if you have an intense interest in a particular
algorithm, you won't find a better reference.
Construction Practices
Code Complete, Steve McConnell. McConnell's book is an exhaustive compendium of all the detailed software-
construction level practices that make the difference between readable, maintainable, extendible programs and
disorganized mish-mashes that become unworkable after initial construction.
Programming Pearls, Jon Bentley. This book provides terrific insight into the functioning of the expert
programmer's mind. In each essay, Bentley walks the reader through the thought processes he uses to solve detailed
programming problems. Along the way he introduces the concepts of Big-O notation, approaches to performance
tuning, back-of-the-envelope calculations, and many other topics. Reading this book thoughtfully is like working
through an apprenticeship with a master programmer.
Practice of Programming, Brian Kernighan and Rob Pike. This book is written by two C/Unix gurus and
contains a good, solid discussion of key code-level and design level issues. Chapter 4, on interface design, covers a
topic that doesn't get much coverage in other books.
Writing Solid Code, Steve Maguire. This book describes key software-construction practices used at Microsoft. It
explains how to minimize defects by using compiler warnings, protecting your code with assertion statements,
fortifying subsystems with integrity checks, designing unambiguous function interfaces, checking code in a
debugger, and avoiding risky programming practices.
Programming on Purpose: Essays on Software Design, P. J. Plauger. This is a refreshing collection of essays
that were originally published in Computer Language magazine. Plauger is a master designer and takes up a variety
of topics having as much to do with being a designer as with design in the abstract. What makes the essays
refreshing is that Plauger ranges freely over the entire landscape of design topics rather than restricting himself to a
discussion of any one design style. The result is uniquely insightful and thought provoking.
Programmers at Work, Susan Lammers. This book contains interesting interviews with many of the pioneers of
personal computing, including Bill Gates, Gary Kildall, Dan Bricklin, and others.
Periodicals
Software Development. This magazine focuses on programming issues, less on tips for specific environments than
the general issues you face as a professional programmer. The quality of the articles is quite good. It also includes
product reviews.
IEEE Software. This magazine focuses on software topics and is published bimonthly. It's a good source of
information on software-development methods and other leading-edge software topics. It publishes many articles by
researchers and makes an earnest attempt to print research on practical topics which are of use to professional
programmers. It isn't always as practical as I (SteveMcC) would like it to be, but, in my opinion, it's still the most
valuable magazine a programmer can subscribe to. [This review was written in 1992.]
Database Design
"A Simple Guide to Five Normal Forms in Relational Database Theory," William
Get the article A
Kent
Get the article A "Process Driven Data Design," Frank Sweet
Get the article A "The Power of Stored Procedures," David McGoveran
Buy the book - Fundamentals of Database Systems, Ramez Elmasri and Shamkant B. Navathe
Design in General
Buy the book A Conceptual Blockbusting, James L. Adams
Buy the book - How to Solve It, G. Polya
Periodicals
Subscribe - Software Development
Subscribe - IEEE Software
Subscribe - IEEE Computer
Subscribe - Communciations of the ACM
Construction Practices
Software Implementation, Michael Marcotty. Marcotty discusses the general issues involved in constructing
software by focusing on abstraction, complexity, readability, and correctness. The first part of the book discusses the
history of programming, programming subculture, programming teams, and how typical programmers spend their
time. The book is written with wit and style, and the first 100 pages on the "business of programming" are especially
well done.
Database Design
Fundamentals of Database Systems, Ramez Elmasri and Shamkant B. Navathe. You can find a lot of good
books on database design and construction, and this is one of them. Even if you don't use a "database," you'll still
benefit from knowing database concepts. For example, every programmer should be familiar with the key concept of
"normal form." If you use files in your programs, you're using a database, and you can benefit from many database
concepts regardless of how small or informal your program is.
Software Design
Object Oriented Analysis and Design, Grady Booch. Booch’s book discusses the theoretical and practical
foundations of object-oriented design for about 300 pages then has 175 more pages of object-oriented application
development in C++. No one has been a more active advocate of object-oriented design than Grady Booch, and this
is the definitive volume on the topic.
Design Patterns, Erich Gamma, et al. [From the Preface]: "It's a book of design patterns that describe simple and
elegant solutions to specific problems in object-oriented software design....Once you understand the design patterns
and have had an "Aha!" (and not just a "Huh?" experience with them, you won't ever think about object-oriented
design in the same way. You'll have insights that can make your own designs more flexible, modular, reusable, and
understandable--which is why you're interested in object-oriented technology in the first place, right?"
Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Ed Yourdon
and Larry Constantine. This is the classic text on structured design by one of the co-authors (Constantine) of the
original paper on structured design. The book is written with obvious care. It contains full discussions of coupling,
cohesion, graphical notations, and other relevant concepts. Some people have characterized the book as "technically
difficult," but it’s hard to beat learning about a practice from its original inventor.
Practical Guide to Structured Systems Design, Meilir Page-Jones. This is a popular textbook presentation of the
same basic structured-design content as Yourdon and Constantine’s book and is written with energy and humor.
Some people have found Page-Jones’s book to be more accessible than Yourdon and Constantine’s.
Programming on Purpose: Essays on Software Design, P. J. Plauger. This is a refreshing collection of essays
that were originally published in Computer Language magazine. Plauger is a master designer and takes up a variety
of topics having as much to do with being a designer as with design in the abstract. What makes the essays
refreshing is that Plauger ranges freely over the entire landscape of design topics rather than restricting himself to a
discussion of any one design style. The result is uniquely insightful and thought provoking.
"A Rational Design Process: How and Why to Fake It," David Parnas and Paul Clements. This is a classic
article that describes the gap between how programs are really designed and how you sometimes wish they were
designed. The main point is that no one ever really has a rational, orderly design process, but that aiming for it
makes for better designs in the end.
Pattern Oriented Software Architecture: A System of Patterns, Frank Buschmann, et al. This book takes
design patterns to the architectural level, discussing architectural patterns of layers, blackboard, pipes, brokers,
model-view-controller, and others.
Software Architecture: Perspectives on an Emerging Discipline by Mary Shaw and David Garlan. This was
the first book published on software architecture. It covers some of the same concepts as Buschmann's Pattern
Oriented Software Architecture, but comes across as much more academic.
"On the Criteria to Be Used in Decomposing Systems into Modules," David L. Parnas (also in Yourdon 1979,
Freeman and Wasserman 1983). The classic paper that introduced the concept of "information hiding."
"Designing Software for Ease of Extension and Contraction," David L. Parnas (also in Freeman and
Wasserman 1983).
"The Modular Structure of Complex Systems," David Lorge Parnas, Paul C. Clements, and David M. Weiss.
"Structured Design," W. Stevens, G. Myers, and L. Constantine. This is the original paper on structured design.
The books make better presentations of the concepts, but once you've read the books the paper is interesting mainly
for its historical value.
Software Creativity, Robert L. Glass. This 1995 book should have been the breakthrough book that explored a
little discussed and less understood aspect of software development: the role of creativity. Glass discusses creativity
versus discipline, theory versus practice, heuristics versus methodology, process versus product, and many of the
other dichotomies that define the software field. This book should have been the breakthrough book for creativity
that Peopleware was for human factors. This book is out of print.
Object-Oriented Software Construction, Bertrand Meyer. Meyer is one of the hardest of the hard-core object-
oriented programming advocates, and this book contains a forceful defense of pure object-oriented programming--
including inheritance, multiple inheritance, and polymorphism. It contains a lively criticism of traditional, structured
techniques, as well as hybrid approaches, such as the one suggested in Code Complete.
Design in General
Conceptual Blockbusting, James L. Adams. This book will teach you more about software design than many
books that focus specifically on software design. Software design books seem to focus exclusively on the activity of
partitioning a system up into pieces, giving guidelines for how to evaluate a particular partitioning. They generally
ignore aspects of design such as algorithm development and the process of coming up with the partitioning in the
first place. These are the areas in which Conceptual Blockbusting excels. Adams is an engineering professor at
Stanford and teaches an engineering design course, so this book's content is on target for software developers.
How to Solve It, G. Polya. This book is essentially 1945's version of David Parnas and Paul Clement's paper, "A
Rational Design Process: How and Why to Fake It" (IEEE Transactions on Software Engineering, February 1986,
pp. 251-257). Polya's book is about mathematical theorems, but if you replace "mathematical theorem" with
"software design," the book is an outstanding software design book. Polya points out that the process used to create
a design is different than the process used to explain it. The explanation should be neat and orderly, progressing in
an orderly way from premises to conclusions. The creation of the design is hardly so tidy. The designer creates
designs that don't work, explores dead ends, and throws away more work than he keeps. This book sheds more light
on the activity of software design (as opposed to the result) than any software design book I've seen. It makes it clear
that problem solving isn't a deterministic activity, and that adherence to any single methodology is like walking with
your feet in chains.
Software Industry Overview
"Software’s Chronic Crisis," W. Wayt Gibbs. This article describes some recent software projects that have been
plagued by changing requirements including the Denver airport’s baggage-handling software and the FAA’s air-
traffic-control workstation software.
Software Runaways, Robert L. Glass. Glass highlights research findings about runaway software projects and
then spends most of the book exploring case studies of high profile runaways. He includes the Denver airport
baggage handling system, the FAA's AAS system, Westpac Bank's $150M CASE disaster, and the IRS's $50 billion
debacle. He wraps up the book by drawing lessons from the runaways.
"Programmer Performance and the Effects of the Workplace," Tom DeMarco and Tim Lister. This precursor
to Peopleware contains a meatier, more condensed explication of the office environment analysis presented in
Peopleware.
Peopleware, Tom DeMarco and Timothy Lister. The genesis of Peopleware was an obscure 1985 paper called
"Programmer Performance and the Effects of the Workplace" (Proceedings of the 8th International Conference on
Software Engineering, August 1985, pp. 268-272). The 1985 paper contains a higher information-to-explanation
ratio than the book, and I think in some ways the paper is more interesting. The book is also mis-subtitled. The
subtitle says it's about "productive projects and teams," but the discussion of teams is only 35 pages long, and the
book is probably better known for its coverage of the effects of work environment on productivity. Do these points
detract from the book? Not at all. The main message of this book is that software is something that is constructed by
people, and if you want good software, you'd better look out for the welfare of the people creating it. Peopleware
said that first and still says it best.
Constantine on Peopleware, Larry Constantine. This book contains a collection of essays loosely focused on the
role that people play in software development.
Periodicals
IEEE Computer. IEEE Computer Society Publications Office, 10662 Los Vaqueros Cir., PO Box 3014, Los
Alamitos, CA 90720-1264; 714-821-8380, www.computer.org/computer/. This is the flagship publication of the
IEEE Computer society. It publishes articles monthly on a wide spectrum of computer topics and has scrupulous
review standards to ensure the quality of the articles it publishes. Because of its breadth, you'll probably find fewer
articles that interest you than you will in IEEE Software.
Communications of the ACM, ACM, PO Box 12114, Church Street Station, New York, NY 10257. www.acm.org.
This magazine is one of the oldest and most respected computer publications. It has the broad charter of publishing
about the length and breadth of computerology, a subject that's much vaster than it was even a few years ago. Like
IEEE Computer, because of its breadth, you'll probably find that many of the articles are outside your area of
interest.
The magazine tends to have an academic flavor, which has both a bad side and a good side. The bad side is that
some of the authors write in an intentionally confusing style that's designed more to impress readers with their
vocabulary and esoteric grammer rules than to explain their points clearly. The good side is that it contains leading-
edge information that won't filter into the low-brow magazines for years.
Requirements Development
(read at least one of the required books)
Buy the book A Requirements Engineering, A Good Practice Guide, Ian Sommerville and Pete Sawyer
Buy the book A Modern Structured Analysis, Edward Yourdon
Buy the book A Software Requirements, Karl Wiegers
Exploring Requirements: Quality Before Design, Donald C. Gause and Gerald
Buy the book -
Weinberg.
Buy the book - Rethinking Systems Analysis and Design, Gerald Weinberg
Buy the book - Structured Analysis and Systems Specification: Tools and Techniques, Tom DeMarco
Buy the book - Strategies for Real-Time System Specification, Derek J. Hatley and Imtiaz A. Pirbhai
Software Requirements & Specifications: A Lexicon of Practice, Principles and
Buy the book -
Prejudices, Michael Jackson
Buy the book - Software Requirements Engineering, Richard H. Thayer and Merlin Dorfman, eds
Technical Reviews
"Design and Code Inspections to Reduce Errors in Program Development," Michael
Get the article A
E. Fagan
Get the article A "Advances in Software Inspections," Michael E. Fagan
Testing
(read at least one of the required books)
Buy the book A Testing Computer Software, Cem Kaner, et al
Buy the book A The Art of Software Testing, Glenford Myers
Buy the book A Complete Guide to Software Testing, Bill Hetzel
Buy the book - Software Testing Techniques, Boris Beizer
Buy the book - The Craft of Software Testing, Brian Marick
Project Management
Recommended Approach to Software Development, NASA Goddard Space Flight
Download A
Center
Download A Manager's Handbook for Software Development, NASA Goddard Space Flight Center
Buy the book A Rapid Development, Steve McConnell
Buy the book - Principles of Software Engineering Management, Tom Gilb
Buy the book - Creating a Software Engineering Culture, Karl Wiegers
Buy the book - Assessment and Control of Software Risks, Capers Jones
Buy the book - Controlling Software Projects, Tom DeMarco
Buy the book - Software Engineering Project Management, Richard H. Thayer, ed
Buy the book - Software Management, Donald J. Reifer, ed
Buy the book - A Manager’s Guide to Software Engineering, Roger Pressman
Buy the book - Managing a Programming Project, 3d Ed, Philip Metzger and John Boddie
Configuration Management
Get the article A "Elements of Software Configuration Management," Edward H. Bersoff
"Impacts of Life Cycle Models on Software Configuration Management," Edward H.
Get the article A
Bersoff and Alan M. Davis
Metrics
Download - Software Measurement Guidebook, NASA Goddard Space Flight Center
Practical Software Metrics for Project Management and Process Improvement, Robert
Buy the book -
B. Grady
Buy the book - Applied Software Measurement: Assuring Productivity and Quality, Capers Jones
Software Industry
Buy the book - Soul of a New Machine, Tracy Kidder
Buy the book - Microsoft Secrets, Cusumano, Michael and Richard Selby
Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at
Buy the book -
Microsoft, Pascal Zachary
General Management
Buy the book A Built To Last, James C. Collins and Jerry I. Porras
Buy the book - In Search of Excellence,Tomas J. Peters and Robert H. Waterman, Jr
Buy the book - The E-Myth, Michael L. Gerber
Buy the book - High Output Management, Andrew S. Grove
Periodicals
Subscribe - Software Development
Subscribe - IEEE Software
Subscribe - IEEE Computer
Subscribe - Communciations of the ACM
Requirements Development
Requirements Engineering, A Good Practice Guide, Ian Sommerville and Pete Sawyer. Description TBD.
Modern Structured Analysis, Edward Yourdon. Yourdon’s book contains a survey of requirements specification
and analysis circa 1989 including modeling tools, the requirements-gathering process, and related issues. One of the
most useful sections is hidden in an appendix: "Interviewing and Data Gathering Techniques."
Software Requirements: A Pragmatic Approach, Karl Wiegers. This is a practical book that focuses more on
what to do than on requirements theory. You can download chapters from the author's website at
http://www.processimpact.com. The published version will be available in October 1999.
Exploring Requirements: Quality Before Design, Donald C. Gause and Gerald Weinberg. Gause and Weinberg
chart an untraditional course through the requirements-management terrain. They discuss ambiguity, meetings,
conflict resolution, constraints, expectations, reasons that methodologies aren’t enough, and quite a few other topics.
They mostly avoid the topics that other requirements books include and include the topics that the other books leave
out.
Rethinking Systems Analysis and Design, Gerald Weinberg. This is an entertaining collection of essays that
stands some traditional requirements advice on its head. .
Structured Analysis and Systems Specification: Tools and Techniques, Tom DeMarco. This classic book was
the first written on requirements specification techniques.
Strategies for Real-Time System Specification, Derek J. Hatley and Imtiaz A. Pirbhai. This book extends
structured analysis technique by adding timing considerations.
Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices, Michael Jackson.
This book is organized in a quirky A-Z format, but contains some good insights into requirements development.
Software Requirements Engineering, Richard H. Thayer and Merlin Dorfman, eds. This IEEE Tutorial
contains a collection of the best and most influential papers written about software requirements development.
Technical Reviews
"Design and Code Inspections to Reduce Errors in Program Development," Michael E. Fagan.
"Advances in Software Inspections," Michael E. Fagan.
These two articles are written by the developer of inspections. They contain the meat of what you need to know to
run an inspection including the standard inspection forms.
Software Testing
Testing Computer Software, Cem Kaner, et al. I (SteveMcC) think this is the best testing book available. It's
written by a practicing tester and is steeped in the realities of testing shrink-wrap software.
The Art of Software Testing, Glenford Myers. After more than twenty years, this is still one of the best testing
books available. Myers knows his subject, and the contents are straightforward: A Self-Assessment Test; The
Psychology and Economics of Program Testing; Program Inspections, Walkthroughs, and Reviews; Test-Case
Design; Module Testing; Higher-Order Testing; Debugging; Test Tools and Other Techniques. It short (177 pages)
and readable. The quiz at the beginning gets you started thinking like a tester and demonstrates how many ways
there are to break a piece of code.
Complete Guide to Software Testing, Bill Hetzel. In addition to what Myers covers, Hetzel discusses testing of
requirements and designs, regression testing, purchased software, and management considerations. At 284 pages, it's
also relatively short, and the author has a knack for presenting powerful technical concepts understandably.
Software Testing Techniques, Boris Beizer. This book is a long treatment of the subject matter (550 pages).
Whereas Myers and Hetzel touch on related topics, like reviews and inspections, Beizer sticks strictly to testing. He
covers a few kinds of testing that aren't discussed in other books, such as data-flow testing. In spite of its scope, the
contents are frequently eccentric and often don't represent mainstream testing ideas. For example, the book doesn't
include any significant discussion of testing documentation or the IEEE/ANSI testing standards, but it does include
an argument that most variables should be made global rather than local. Inspections and walkthroughs aren't
defined in the glossary, but "Incredible Hulk" is. If other books are available, read one of those first. Beizer's book is
worth having as an auxiliary reference.
The Craft of Software Testing, Brian Marick. TBD.
Configuration Management
"Elements of Software Configuration Management," Edward H. Bersoff. IEEE Transactions on Software
Engineering, vol. SE-10, no. 1 (January 1984), pp. 79-87. This paper succinctly describes the elements of software
configuration management.
"Impacts of Life Cycle Models on Software Configuration Management," Edward H. Bersoff and Alan M.
Davis, Communications of the ACM, vol. 34, no. 8 (August 1991), pp. 104-118. This article describes how SCM is
affected by newer approaches to software development, especially prototyping approaches.
Metrics
Software Measurement Guidebook. Document number SEL-94-002. Greenbelt, Maryland: Goddard Space Flight
Center, NASA, 1994. This is an excellent introductory book that describes the basics of how and why to establish a
measurement program. Among other highlights, it includes a chapter of experienced-based guidelines, lots of sample
data from NASA projects, and an extensive set of sample data-collection forms. Obtain a single copy for free from
the SEL’s Web site at http://sel.gsfc.nasa.gov/.
Practical Software Metrics for Project Management and Process Improvement, Robert B. Grady. This book is
the follow-on to Grady and Caswell’s earlier book and extends the discussion of lessons learned at Hewlett-Packard.
It contains a particularly nice presentation of a set of software business-management graphs, each of which is
annotated with the goals and questions that the graph was developed in response to.
Applied Software Measurement: Assuring Productivity and Quality, Capers Jones. This book contains Jones’s
recommendations for setting up an organization-wide measurement program. It is a good source of information on
functional metrics (the alternative to lines-of-code metrics). It describes problems of measuring software, various
approaches to measurement, and the mechanics of building a measurement baseline. It also contains excellent
general discussions of the factors that contribute to quality and productivity. I (SteveMcC) have found so many
typographical errors, inconsistencies, and questionable statistical practices that I can no longer recommend it as
wholeheartedly as I did in Code Complete. Read it for the general messages but don't put too much stock in any
specific numbers.
Software Industry
Microsoft Secrets, Cusumano, Michael and Richard Selby. This collection of Microsoft best practices describes
how Microsoft develops software when it's working at its best.
Soul of a New Machine, Tracy Kidder. This Pulitzer prize winning account of the development of Data General's
Eagle computer captures what it feels to work on a commitment-based project. It is about a hardware project, but the
dynamics are so similar to software projects that the project description will be painfully vivid to most software-
oriented readers.
Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft, Pascal
Zachary. This book contains a quick-reading account of the development of the first release of Windows NT. It
doesn't contain a lot of technical detail, but does a good job of conveying what it feels like to work on a high
pressure project at Microsoft. It is written in the same vein as Soul of a New Machine.
General Management
Built To Last, James C. Collins and Jerry I. Porras. Collins and Porras took the very interesting approach of
studying pairs of companies in similar industries, each of which had been in business at least 50 years, but one of
which is regarded as the industry leader and the other as second best. The lessons drawn from these comparisons
provide food for thought for anyone shaping a startup company or trying to decide whether he really wants to work
for his current company. The person who first recommended this book to me (SteveMcC) said that he had just
completed an MBA, and that he learned more from reading this book than from his whole MBA program.
In Search of Excellence,Tomas J. Peters and Robert H. Waterman, Jr. This book almost instantly achieved
classic status when it was published in 1982. Although it has been eclipsed by newer books, the basic messages are
still worth reading. It makes a nice complement to Built to Last.
High Output Management, Andrew S. Grove. Andy Grove is one of the founders of Intel and has strong opinions
about how to manage a company in a competitive technical industry. Grove takes a strongly quantitative approach to
management. The book contains important discussions of fixing defects at the "least value" stage, importance of
performance reviews, and other key topics.
The E-Myth, Michael L. Gerber. Gerber observes that 80% of small businesses fail within the first 5 years and
recommends that small business owners spend time working on their businesses in addition to working in them. His
specific approach centers on documenting roles, responsibilities, and processes. For software types, the book reads
like a CMM Level 2 approach to running the business part of a business.
Periodicals
IEEE Computer. IEEE Computer Society Publications Office, 10662 Los Vaqueros Cir., PO Box 3014, Los
Alamitos, CA 90720-1264; 714-821-8380, www.computer.org/computer/. This is the flagship publication of the
IEEE Computer society. It publishes articles monthly on a wide spectrum of computer topics and has scrupulous
review standards to ensure the quality of the articles it publishes. Because of its breadth, you'll probably find fewer
articles that interest you than you will in IEEE Software.
Communications of the ACM, ACM, PO Box 12114, Church Street Station, New York, NY 10257. www.acm.org.
This magazine is one of the oldest and most respected computer publications. It has the broad charter of publishing
about the length and breadth of computerology, a subject that's much vaster than it was even a few years ago. Like
IEEE Computer, because of its breadth, you'll probably find that many of the articles are outside your area of
interest.
The magazine tends to have an academic flavor, which has both a bad side and a good side. The bad side is that
some of the authors write in an intentionally confusing style that's designed more to impress readers with their
vocabulary and esoteric grammer rules than to explain their points clearly. The good side is that it contains leading-
edge information that won't filter into the low-brow magazines for years.
How to Read a Book by Mortimer J. Adler stayed at the top of the nationwide best seller
list for more than a year when it was originally published in 1940 (Simon & Schuster).
Adler brought his experience as long-time editor of Encyclopedia Britannica to bear on
the project. Revised and updated in 1972, the book is still a tremendously practical guide
to the various kinds of reading we do both personally and professionally. Adler includes
sections on general reading as well as specialized sections on reading fiction, history,
philosophy, science, and mathematics.
Reading Levels
Adler differentiates between 4 levels of reading. "Elementary reading" is the most basic
reading and is characterized by learning to recognize individual words on a page.
"Inspectional reading" is a more advanced level of reading, which is characterized by
trying to get the most out of a book or article within a given amount of time. "Analytical
reading" is still more advanced, and is characterized by trying to get the most out of a
book or article with an unlimited amount of time. "Syntopical reading" is the most
advanced form of reading and involves reading sets of books or articles on a common
topic together in a way that allows you to extract information that might or might not be
present in any of the individual materials studied.
Adler describes several techniques a person can use to read a book or article quickly for
Inspectional reading. You might think of this as systematic skimming. He suggests that
you first study the title. What does the title tell you about the kind of book or article it is?
If it’s a book, next study the table of contents. What subject areas are covered? What is
the book’s emphasis? Can you infer the author’s main points from the table of contents?
Next, read the preface. In a well-written preface, the author will summarize why the book
was written, who the book was written for, and what you should expect to get from
reading it. Study the book’s index. The table of contents tells you what the author
planned to talk about, and sometimes the index tells you what the author actually did talk
about. After that, study the introductory text in each chapter, and then dip into the first
and last chapters of the book.
Technical articles are a little more difficult than books in that they don’t typically include
tables of contents, indexes, and so on. For technical articles, you might consider reading
the abstract, introduction, and conclusion, then reading the introductory text in each
section.
If what you’re after is a general understanding of the main points of a book or article
rather than the detailed logic, Inspectional reading may be the only kind of reading you’ll
need to do. If you later need a more detailed understanding of the book’s contents, your
Inspectional reading will have prepared you to find that information quickly. Prior to
reading this advice in How to Read a Book, I had always felt a little guilty about not
finishing a book. But Adler makes a strong case for not going beyond Inspectional
reading unless you need to. I found his advice liberating; he told me that it was
acceptable to read a book in this way, and gave me a systematic method for doing
something I had previously been doing only haphazardly.
In case you do need to perform Analytical reading, Inspectional reading prepares you for
that. In reading a book or article for understanding rather than just for information, you
need to both acquire an understanding of the way the author has organized the subject
matter and an understanding of the subject matter details. By jumping into the details
first, starting at page 1 and reading through to the end, you have to acquire both of these
kinds of knowledge simultaneously, which is very difficult. By performing Inspectional
reading first, you acquire an understanding of the organizational framework quickly, and
you can then fit the details into the framework during your more detailed reading of
pages1 to n.
Questions First, Answers Second
One of the rules of Analytical reading is that you should try to state as clearly as possible
the problem that the author has tried to solve. In reading a paper submitted to IEEE
Software, I always ask, "why would Software’s readers care about this paper? Does it
address a real problem? In what specific way will it make our readers’ lives easier?"
A related idea is that the more you engage in a dialog with the author of a book or article,
the better your understanding is likely to be. If you’ve performed Inspectional reading
first, you will probably have a long list of questions for the author: "Why did you include
subject X and not subject Y? Do you think subject Y is unimportant? Is it outdated? Did
you simply not know about it? Does it really make sense to discuss subject B before
subject A?" In addition to such specific questions, Adler proposes four generic questions
that you can ask of each book or article you read:
1. What is the book or article about as a whole?
2. What is being said in detail, and how is it being said?
3. Is the book or article true in whole or in part? You have to read the
material carefully enough to answer the first two questions before you can
answer this one.
4. What of it? How does the author’s conclusion relate to you or your
work?
As Editor of Software, I have a more specific set of questions I ask of each manuscript that’s
submitted. Bearing these questions in mind helps me understand what the article is about.
First, I have to assign each submitted article a "CR Code," which is a classification
scheme IEEE Software uses to categorize all submitted articles and send them to
reviewers who have indicated an interest in the same subject. Often, I can assign the CR
code simply by reading the article’s title, abstract, and conclusion. The first question I
ask, then, is a variation of Adler’s "what is this about?" My question is, "What is the
article’s alphanumeric CR code?" If I have difficulty assigning a CR Code, that is my
first clue that the purpose of the article might be unclear, though sometimes it is our
classification scheme that is unclear.
The second question I ask of each submitted article is "What genre is it?" Every article
submitted to IEEE Software is assigned one of the genres that are highlighted in this
issue’s focus, and those genres are later used to guide the peer reviewers’ review of the
article. The genre designation amounts to a partial answer to Adler’s question of "What
of it?" Is the article a How To? A Case Study? A Tool Report? A Practice Tutorial? A
Research Tutorial? An Applied Research Result? An Experience Report? An Essay? Or
does it not fit neatly into any of our defined genres?
When the peer reviews for an article come back, I have to consider each of Adler’s four
questions in determining whether an article is suitable for publication. I rely on reviewer
comments to help me determine whether the article is "true in whole or in part" and
whether it will be useful to our readers. If we receive an article in a specialized area, such
as an Applied Research Report, the article’s vocabulary might be too specialized for me
to understand completely. I have to revert to "elementary reading" for that kind of article
because I struggle just to understand some of the individual words.
Because IEEE Software is a magazine, not a journal, before publication we try to rework
articles of this kind so that our typical reader will be able to read the article at the
Analytical level. Before that happens, reviewers who know more about the specialized
subject matter than I do help me to determine the answer to Adler’s second question,
"What is being said in detail, and how is it being said?" Sometimes, the reviewers
conclude that nothing is being said! In that case, we reject the article. Other times,
sometime valuable is being said but it isn’t being said clearly enough for our magazine,
and in those cases we work with the author to revise the material so that our typical
reader will be able to benefit from the author’s insights.
Editor: Steve McConnell, Construx Software, 11820 Northup Way #E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com - WWW: http://www.construx.com/stevemcc/