Algorithms (One of the Following) L Buy the Book -  Introduction to Algorithms, Thomas H

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 -  Algorithms in C++, Robert Sedgewick Buy vol.1 Buy vol.2 -  The Art of Computer Programming (vols. 1-3), Donald Knuth Buy vol.3

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

Software Development Overview Buy the book. 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 Get the article A Parnas Get the article 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

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

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

User Interface Design Buy the book A  The Design of Everyday Things, Donald A. Norman  Designing the User Interface: Strategies for Effective Human-Computer Interaction, Buy the book A Ben Shneiderman Buy the book 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

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

Software Functional Design Buy the book I  Object Oriented Analysis and Design, Grady Booch Buy the book I  Design Patterns, Erich Gamma, et al.  Structured Design, Edward Yourdon and Larry Constantine (or see Meilir Page- Buy the book I Jones's book instead)  Practical Guide to Structured Systems Design, Meilir Page-Jones, (or see Yourdon Buy the book A and Constantine's book instead) Buy the book A  Software Creativity, Robert L. Glass  "A Rational Design Process: How and Why to Fake It," David Parnas and Paul Get the article A Clements Get the article A  "On the Criteria to Be Used in Decomposing Systems into Modules," David L. Parnas Get the article A  "Designing Software for Ease of Extension and Contraction," David L. Parnas  "The Modular Structure of Complex Systems," David Lorge Parnas, Paul C. Get the article A Clements, and David M. Weiss  Pattern Oriented Software Architecture : A System of Patterns, Frank Buschmann, et Buy the book - al. Buy the Book -  Programming on Purpose: Essays on Software Design, P. J. Plauger  Software Architecture : Perspectives on an Emerging Discipline Buy the book - by Mary Shaw and David Garlan Get the article -  "Structured Design," W. Stevens, G. Myers, and L. Constantine Buy the book -  Object-Oriented Software Construction, Bertrand Meyer

Design in General Buy the book A  Conceptual Blockbusting, James L. Adams Buy the book -  How to Solve It, G. Polya

Software Industry Overview Get the article A  "Software’s Chronic Crisis," W. Wayt Gibbs  "Programmer Performance and the Effects of the Workplace," Tom DeMarco and Tim Get the article A Lister Buy the book -  Software Runaways, Robert L. Glass Buy the book -  Peopleware, Tom DeMarco and Timothy Lister Buy the book -  Constantine on Peopleware, Larry Constantine

Software Development Overview Buy the book 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.

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. 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 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. 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 further- reading 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 leading- edge information that won't filter into the low-brow magazines for years.

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.

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

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: [email protected] - WWW: http://www.construx.com/stevemcc/