Level 9 Reading List
[ladder home page] [ladder overview] [reading list] [pyramid]
 Required reading
 Recommended Reading
 Appropriate Optional Reading
The top list is a recommendation by category. Detailed book descriptions follow the summary table.
R
Algorithms (one of the following)
L
Buy the book
-  Introduction to Algorithms, Thomas H. Cormen, et al
Buy the book
-  Data Structures and Algorithms, Aho, Hopcraft, and Ullman
Buy the book
Buy vol.1
Buy vol.2
Buy vol.3
-  Algorithms in C++, Robert Sedgewick
-  The Art of Computer Programming (vols. 1-3), Donald Knuth
Buy the book
Construction Practices
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
Buy the book.
Software Development Overview
A  201 Principles of Software Development, Alan M. Davis
Get the article
A  "The Humble Programmer," Edsger Dijkstra
 "Software Engineering Programmes are not Computer Science Programmes," David
A
Parnas
A  "They Write the Right Stuff ," Charles Fishman
Buy the book
-  Software Engineering, Ian Sommerville
Buy the book
-  Software Engineering: A Practitioner's Approach, Roger Pressman
Get the code
Professional Ethics
A  Software Engineering Code of Ethics and Professional Practice, ACM/IEEE-CS
Subscribe
Periodicals
-  Software Development
Subscribe
-  IEEE Software
Get the article
Get the article
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 softwareconstruction 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.
Software Development Overview
201 Principles of Software Development, Alan M. Davis. 201 Principles provides an easy-to-read introduction to
the critical issues in software development. Davis’s book prepares you to recognize key issues when other books
discuss them and when they crop up on your own projects.
"The Humble Programmer," Dijkstra, Edsger. This classic paper helped begin the inquiry into how much
computer programming depends on programmers' mental abilities. Dijkstra has persistently trumpeted the message
that the essential task of programming is mastering the enormous complexity of computer science. He argues that
programming is the only activity in which humans have to master nine orders of magnitude difference between the
lowest level of detail and the highest. This paper would be interesting reading solely for its historical value, but
many of its themes sound fresh 20 years later. It also gives a good sense of what it was like to be a programmer in
the early days of computer science.
"Software Engineering Programmes are not Computer Science Programmes," David Parnas. This exceptional
article describes the contents of the Software Engineering program at McMaster University. The premise of the
article is that it is easiest to understand a software engineering curriculum by comparing it to a computer science
curriculum.
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.]
Copyright © 1999 Construx Software Builders, Inc.
Level 10 Reading List
[ladder home page] [ladder overview] [reading list] [pyramid]
 Required reading
 Recommended Reading
 Appropriate Optional Reading
The top list is a recommendation by category. Detailed book descriptions follow the summary table.
R
Construction Practices
L
Buy the book
-  Software Implementation, Michael Marcotty
Buy the book
User Interface Design
A  The Design of Everyday Things, Donald A. Norman
 Designing the User Interface: Strategies for Effective Human-Computer Interaction,
A
Ben Shneiderman
A  Usability Engineering, Jakob Nielsen
Buy the book
-  The Elements of Friendly Software Design, Paul Heckel
Buy the book
-  About Face: The Essentials of User Interface Design, Alan Cooper
Buy the book
-  The Art of Human-Computer Interface Design, Brenda Laurel, ed
Get the article
Database Design
A  "A Simple Guide to Five Normal Forms in Relational Database Theory," William 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
Buy the book
Software Functional Design
I  Object Oriented Analysis and Design, Grady Booch
Buy the book
Buy the book
Buy the book
Buy the book
Buy the book
Buy the book
Get the article
Get the article
Get the article
Get the article
Buy the book
Buy the Book
I  Design Patterns, Erich Gamma, et al.
 Structured Design, Edward Yourdon and Larry Constantine (or see Meilir Page-Jones's
I
book instead)
 Practical Guide to Structured Systems Design, Meilir Page-Jones, (or see Yourdon and
A
Constantine's book instead)
A  Software Creativity, Robert L. Glass
 "A Rational Design Process: How and Why to Fake It," David Parnas and Paul
A
Clements
A  "On the Criteria to Be Used in Decomposing Systems into Modules," David L. Parnas
A  "Designing Software for Ease of Extension and Contraction," David L. Parnas
 "The Modular Structure of Complex Systems," David Lorge Parnas, Paul C. Clements,
A
and David M. Weiss
 Pattern Oriented Software Architecture : A System of Patterns, Frank Buschmann, et
al.
-  Programming on Purpose: Essays on Software Design, P. J. Plauger
Buy the book
-
 Software Architecture : Perspectives on an Emerging Discipline
Get the article
by Mary Shaw and David Garlan
-  "Structured Design," W. Stevens, G. Myers, and L. Constantine
Buy the book
-  Object-Oriented Software Construction, Bertrand Meyer
Buy the book
Design in General
A  Conceptual Blockbusting, James L. Adams
-  How to Solve It, G. Polya
Buy the book
Buy the book
Software Industry Overview
A  "Software’s Chronic Crisis," W. Wayt Gibbs
 "Programmer Performance and the Effects of the Workplace," Tom DeMarco and Tim
A
Lister
-  Software Runaways, Robert L. Glass
Buy the book
-  Peopleware, Tom DeMarco and Timothy Lister
Buy the book
-  Constantine on Peopleware, Larry Constantine
Buy the book
Software Development Overview
A  Software Project Survival Guide, Steve McConnell
Buy the book
A  Mythical Man-Month, Fred Brooks
Get the article
A  "No Silver Bullets--Essence and Accidents of Software Engineering," Fred Brooks
Get the article
A  "Understanding and Controlling Software Costs," Barry Boehm and Phillip Papaccio
Buy the book
-  Wicked Problems, Righteous Solutions, Peter DeGrace and Leslie Hulet Stahl
Buy the book
-  The Deadline, Tom DeMarco
Buy the book
-  Debugging the Development Process, Steve Maguire
Buy the book
-  Software Engineering, Ian Sommerville
Buy the book
-  Software Engineering: A Practitioner's Approach, Roger Pressman
Buy the book
-  Dynamics of Software Development, Jim McCarthy.
Subscribe
Periodicals
-  Software Development
Subscribe
-  IEEE Software
Subscribe
-  IEEE Computer
Subscribe
-  Communciations of the ACM
Get the article
Get the article
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.
User Interface Design
Designing the User Interface: Strategies for Effective Human-Computer Interaction, Ben Shneiderman. See
comments on next book, below.
The Elements of Friendly Software Design, Paul Heckel. These two books cover similar territory in different
ways. Shneiderman proposes specific, detailed engineering guidelines for use of color, response time, command
structures, menu layouts, and many other aspects of user-interface design. He suggests specific procedures for
improving designs including prototyping and iterative testing. Most of his recommendations have been verified by
scientific tests. His approach is careful, methodical, and scientific.
Heckel's approach is more free wheeling. Rather than providing detailed procedures, he provides a set of 30
inspirational design heuristics. He argues that interface design is essentially a communication exercise like writing,
speaking, or filmmaking and draws an elaborate, thought-provoking analogy between designing a user interface and
making a movie. In contrast to Shneiderman's summary of current laboratory results, Heckel provides an
adventurous look into the possibilities of the art.
Both books are valuable in their own terms. Heckel's is more fun. Shneiderman's is on more solid ground. They
make a good, complementary pair.
Usability Engineering, Jakob Nielsen. [From the Author]: The basic philosophy of the book is YOU CAN DO IT!
It is about cheap and fast methods that anybody can use in any interface design project (whether Web design,
software design, or gadget design) to drastically improve usability. It is quite common to be able to cut users'
learning time in half (thus cutting your training budget or support center costs by a similar amount).
The Design of Everyday Things, Donald A. Norman. Norman's book isn't explicitly about software design. It's
about user-interface design of everyday things: doors, pitchers, radios, stoves, and so on. Regardless of that fact, it's
hard to find any part of the book that doesn't apply directly to designing software user interfaces. Because Norman
isn't obligated to focus on software examples, he ranges over a broader field than most software-user-interface books
do, and that range of topics is inspirational. I'd read it again just for the description of opening doors the wrong way.
If you've ever felt foolish for pulling a door that says "push," read this book; it's not your fault!
About Face: The Essentials of User Interface Design, Alan Cooper. [Publisher's Description]: The "father" of
Visual Basic, Alan Cooper, presents a methodology of user interface design that he has distilled from many years of
creating award-winning personal computer software. This book does not focus on code; instead it discusses highly
technical topics in clear English. Readers may not agree with everything Cooper has to say about software design,
but they will find his ideas pertinent, thought-provoking, and perceptive.
The Art of Human-Computer Interface Design, Brenda Laurel, ed. This is a collection of articles written by
people prominent in interface design. Like any collection of articles, some people's ideas are better than others, but
this collection contains some gems. My favorite is the article by Alan Kay, the researcher who pioneered Smalltalk,
icons, graphical windows, other interface technologies that comprise the heart of modern computing. His article
vibrates with the force of his creative energy and glimpses into what he's planning for computing's future.
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 objectoriented 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 airtraffic-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.
Software Development Overview
Software Project Survival Guide, Steve McConnell. SPSG is responsive to the problem that many people in the
software industry are thrust into positions in which they are given responsibility for the outcome of a software
project but are not given any formal or informal training in how to make that happen. SPSG provides an introduction
to the steps that successful software projects follow that can be read by both technical and nontechnical readers.
Mythical Man-Month, Fred Brooks. Brooks was the manager of IBM's OS/360 development, a mammoth project
that took 5000 work years. He discusses management issues pertaining to small and large teams and presents a
particularly engaging account of chief-programmer teams in this charming collection of essays.
The Deadline, Tom DeMarco. This amusing fictional account of several software projects run concurrently
explores the causes of software project success and failure.
"No Silver Bullets—Essence and Accidents of Software Engineering," Brooks, Frederick P., Jr., Computer,
April 1987, pp. 10-19. In this famous article, Brooks argues that the essential conceptual difficulty of software
development precludes any more order-of-magnitude gains in productivity, reliability, or simplicity.
"Understanding and Controlling Software Costs," Barry Boehm and Phillip Papaccio. This paper introduces
many of the basic economic relationships of software engineering, e.g., the way that defect costs increase over the
course of a project, etc.
Debugging the Development Process, Steve Maguire. This book presents a homespun approach to software
process improvement with an emphasis on minimum bureacracy.
Wicked Problems, Righteous Solutions, Peter DeGrace and Leslie Hulet Stahl. I liked this book from the start,
and the longer I've considered its ideas the more important the book seems. The book describes life cycle models
such as waterfall, evolutionary prototyping, scrum development, and so on. Projects that choose the wrong lifecycle
model for their specific needs will face an uphill battle and risk not finishing at all. For gaining a big-picture
understanding of how software projects, work, this book is hard to beat.
The subtitle of this book is "A Catalog of Modern Software Engineering Paradigms," and it is by far the most
complete description of software lifecycle models available. The book was produced though an unusual
collaboration in which Peter DeGrace provided the useful technical content and Leslie Hulet Stahl provided the
unusually readable and entertaining writing style.
Software Engineering, Ian Sommerville. The fourth edition of this book is a balanced treatment of requirements,
design, quality validation, and management. It contains helpful diagrams and each subject has an annotated furtherreading section. At about 650 pages, it's not necessarily a book you'll read cover to cover, but if you want a
thumbnail description of a topic, it's probably in here. It has a good index.
Software Engineering: A Practitioner's Approach, Roger Pressman. This is an excellent alternative to
Sommerville’s book and is similar in scope and size. Don’t be mislead by the "Practitioner's Approach" in the title;
excellent as it is, this book is better suited to provide an overview of important issues than to serve as a practitioner’s
handbook.
Dynamics of Software Development, Jim McCarthy. McCarthy describes the insider’s view of the Microsoft
milestone process. He describes an essentially grim vision of software development in which Microsoft projects
spend most of their time in what we would call recovery mode.
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 leadingedge information that won't filter into the low-brow magazines for years.
Copyright © 1999 Construx Software Builders, Inc.
Level 11 Reading List
[ladder home page] [ladder overview] [reading list] [pyramid]
 Required reading
 Recommended Reading
 Appropriate Optional Reading
The top list is a recommendation by category. Detailed book descriptions follow the summary table.
Completing a Master of Software Engineering degree in Seattle University's M.S.E. program will be an acceptable
substitute for the following reading list.
R
Software Development Overview
L
Buy the book
A  Wicked Problems, Righteous Solutions, Peter DeGrace and Leslie Hulet Stahl
Get the article
A  "A Spiral Model of Software Development and Enhancement," Barry W. Boehm
Get the article
-  "Applying Process Programming to the Spiral Model," Barry Boehm and F.C. Belz
Buy the book
-  The Psychology of Computer Programming, Gerald M. Weinberg
Buy the book
-  Peopleware, Tom DeMarco and Timothy Lister
Buy the book
-  Software Engineering, Merlin Dorfman and Richard H. Thayer, eds.
Buy the book
Requirements Development
(read at least one of the required books)
A  Requirements Engineering, A Good Practice Guide, Ian Sommerville and Pete Sawyer
Buy the book
A  Modern Structured Analysis, Edward Yourdon
Buy the book
Buy the book
A  Software Requirements, Karl Wiegers
 Exploring Requirements: Quality Before Design, Donald C. Gause and Gerald
Weinberg.
-  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
Buy the book
Buy the book
Buy the book
-
 Software Requirements & Specifications: A Lexicon of Practice, Principles and
Prejudices, Michael Jackson
-  Software Requirements Engineering, Richard H. Thayer and Merlin Dorfman, eds
Get the article
Technical Reviews
 "Design and Code Inspections to Reduce Errors in Program Development," Michael E.
A
Fagan
A  "Advances in Software Inspections," Michael E. Fagan
Buy the book
Testing
(read at least one of the required books)
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
Download
Download
Project Management
 Recommended Approach to Software Development, NASA Goddard Space Flight
A
Center
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
Get the article
Get the article
Get the article
Configuration Management
A  "Elements of Software Configuration Management," Edward H. Bersoff
 "Impacts of Life Cycle Models on Software Configuration Management," Edward H.
A
Bersoff and Alan M. Davis
Buy the book
Metrics
-  Software Measurement Guidebook, NASA Goddard Space Flight Center
 Practical Software Metrics for Project Management and Process Improvement, Robert
B. Grady
-  Applied Software Measurement: Assuring Productivity and Quality, Capers Jones
Buy the book
Software Industry
-  Soul of a New Machine, Tracy Kidder
Download
Buy the book
Buy the book
Buy the book
-  Microsoft Secrets, Cusumano, Michael and Richard Selby
 Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at
Microsoft, Pascal Zachary
Buy the book
General Management
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
Subscribe
Periodicals
-  Software Development
Subscribe
-  IEEE Software
Subscribe
-  IEEE Computer
Subscribe
-  Communciations of the ACM
Software Development Overview
Wicked Problems, Righteous Solutions, Peter DeGrace and Leslie Hulet Stahl. I (SteveMcC) liked this book
from the start, and the longer I've considered its ideas the more important the book seems. The book describes life
cycle models such as waterfall, evolutionary prototyping, scrum development, and so on. Projects that choose the
wrong lifecycle model for their specific needs will face an uphill battle and risk not finishing at all. For gaining a
big-picture understanding of how software projects, work, this book is hard to beat.
The subtitle of this book is "A Catalog of Modern Software Engineering Paradigms," and it is by far the most
complete description of software lifecycle models available. Any approach to software development needs to vary as
the size of the project varies, and DeGrace and Stahl make that point clearly. The section titled "Attenuating and
Truncating" in Chapter 5 discusses customizing software development processes based on project size and
formality. It includes descriptions of models from NASA and the Department of Defense and lots of edifying
illustrations.
The book was produced though an unusual collaboration in which Peter DeGrace provided the useful technical
content and Leslie Hulet Stahl provided the unusually readable and entertaining writing style.
"A Spiral Model of Software Development and Enhancement," Barry W. Boehm. This paper describes a
development model called the "spiral model" and is written by the developer of the idea. Boehm presents the model
as an approach to managing the risk of a software development project, so it's about development generally rather
than integration specifically. Boehm is undoubtedly the world's foremost expert in the big-picture issues of software
development, and the clarity of his explanations reflects the quality of his understanding.
"Applying Process Programming to the Spiral Model," Barry Boehm and F.C. Belz. This is an update on the
Spiral model.
The Psychology of Computer Programming, Gerald M. Weinberg. This book is packed with fascinating
anecdotes about programming. Long before the term "peopleware" was coined, Weinberg was conducting an indepth exploration of computer programming as something done first and foremost by human beings, and only
secondarily as something that happened to involve computers. The sentiment expressed in the original review of the
book in the ACM Computing Reviews is as true today as when it was written:
Every manager of programmers should have his own copy. He should read it, take it to
heart, act on the precepts, and leave the copy on his desk to be stolen by his
programmers. He should continue replacing the stolen copies until equilibrium is
established. (Weiss 1972)
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.
Software Engineering, Merlin Dorfman and Richard H. Thayer, eds. This IEEE Tutorial contains a collection of
influential papers describing many of the best practices in modern software engineering.
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.
Software Project Management
Recommended Approach to Software Development, Revision 3, Document SEL-81-305, Greenbelt,
Maryland: NASA Goddard Space Flight Center, NASA, 1992. The Software Engineering Laboratory’s
Recommended Approach is probably the most practical overview of running a software project that I have read. It is
intended for use specifically with flight dynamics projects, but many of its recommendations are much more broadly
applicable. The book projects the heartening message that software projects are not mysterious, hard-to-control
entities. They are extremely complex entities, but they can be controlled through diligent application of lessons
learned from previous projects. Obtain a single copy for free from the SEL’s Web site at http://sel.gsfc.nasa.gov/.
Manager’s Handbook for Software Development, Revision 1, Document SEL-84-101, Greenbelt, Maryland:
NASA Goddard Space Flight Center, NASA, 1990. The SEL’s Manager’s Handbook is almost as useful as the
Recommended Approach. It is shorter, and the guidelines it presents are focused specifically on software project
management topics. You can order it or download it in the same way as you can the Recommended Approach. You
can obtain a single copy for free by writing to Software Engineering Branch, Code 552, Goddard Space Flight
Center, Greenbelt, Maryland 20771. Obtain a single copy for free from the SEL’s Web site at
http://sel.gsfc.nasa.gov/.
Rapid Development, Steve McConnell. Rapid Development contains general and practical discussions of classic
mistakes, risk management, lifecycle planning, scheduling, motivation, teamwork, and many other topics related to
rapid software development.
Principles of Software Engineering Management, Tom Gilb. Even if you plan to avoid management for your
entire career, it's a good idea to learn something about it for two reasons. It gives you insight into what your
manager does (or what your manager should do), and it helps you to self-manage your own projects. Tom Gilb's
Principles of Software Engineering Management (1988) is a good place to start. Gilb is a good writer, a metrics hot
shot, and a master of quantitative approaches to management. He is keenly aware of leading-edge approaches. After
the first couple of chapters, you can pick and choose your way through his book.
Creating a Software Engineering Culture, Karl Wiegers. This book is about the organizational change needed to
establish a software engineering culture. Readers familiar with basic software engineering practices will want to
focus on Part I: A Software Engineering Culture and Part VI: What To Do on Monday. Readers without deep
backgrounds in process improvement should also read Part III: Improving Your Processes.
Assessment and Control of Software Risks, Capers Jones. Jones set out to catalog the major risks that affect
software projects in a systematic, reference format that includes a description of each risk, severity, methods of
prevention, and methods of control. Jones follows this format in describing 60 specific risks, and he is to be
commended for being one of the earliest people to spot widespread software phenomenon such as excessive
schedule pressure, management malpractice, and many of the other risks he discusses.
I (SteveMcC) have a love/hate relationship with this book, which I give an A+ for concept and a B- for execution.
From a practical viewpoint, the most useful sections are the methods of prevention and control, and the control
sections tend to be skimpy. For example, for the risk of creeping requirements the book discusses only requirements
gathering and specification techniques (prototyping, JAD, etc.), but it doesn't discuss downstream control methods
such as change boards, triage, and so on. At a more fundamental level, the book is marred by lack of consistent
definition of what a "risk" is. Some of the book's risks apply to individual projects, some to whole organizations, and
some to the software industry at large. The dictionary definition of risk is "undesirable outcome," and many of the
risks listed seem to confuse cause and effect. Is "inadequate software engineering curriculum" an undesirable
outcome? How about "false productivity claims"? Jones' frequent polemics against lines of code metrics, the
Software Engineering Institute, and companies that don't have full-fledged metrics programs sound shrill after the
first 100 pages and detract from some of the book's important messages.
Controlling Software Projects, Tom DeMarco. This is a good alternative or complement to Gilb's book. DeMarco
also takes a quantitative approach, and both he and Gilb are somewhat uncommon in that they both emphasize
controlling projects rather than predicting how they will turn out. .
Software Engineering Project Management, Richard H. Thayer, ed. This IEEE Tutorial is a collection of about
45 papers on the topic of managing software projects. The papers are some of the best discussions available on the
topics of planning, organizing, staffing, directing, and controlling a software project. Thayer provides an
introduction to the topics and comments briefly on each paper.
Software Management, Donald J. Reifer, ed. This IEEE Tutorial contains a collection of about 50 papers on the
topic of managing software projects. There's quite a bit of overlap between this book and Thayer's book.
A Manager’s Guide to Software Engineering, Roger Pressman. This might be the best overview available on
general aspects of software project management. It includes introductory sections on estimation, risk analysis,
scheduling and tracking, and the human element. Its only drawback is its use of a question-and-answer format that
might come across as disjointed to some readers. (It does to me.)
Managing a Programming Project, 3d Ed, Philip Metzger and John Boddie. This little book is the classic
introductory project-management textbook. It’s fairly dated now because of its emphasis on the waterfall lifecycle
model and on document-driven development practices. But anyone who’s willing to read it critically will find that
Metzger still has some important things to say about today’s projects and says them well.
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 softwareoriented 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 leadingedge information that won't filter into the low-brow magazines for years.
Copyright © 1999 Construx Software Builders, Inc.
From the Editor
IEEE Software, Vol. 15, No. 6, November/December 1998
How To Read A Technical Article
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/