Handbook of Technical Reviews, Fourth Edition
Handbook of Technical Reviews, Fourth Edition
$19.99
Minimum price
$19.99
Suggested price
Handbook of Technical Reviews, Fourth Edition

Last updated on 2014-06-24

About the Book

About the Author

Gerald M. Weinberg
Gerald M. Weinberg

I've always been interested in helping smart people be happy and productive. To that end, I've published books on human behavior, including Weinberg on Writing: The Fieldstone Method, The Psychology of Computer Programming, Perfect Software and Other Fallacies, and an Introduction to General Systems Thinking. I've also written books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the nine-volume Quality Software series.

I try to incorporate my knowledge of science, engineering, and human behavior into all of my writing and consulting work (with writers, hi-tech researchers, software engineers, and people whose life-situation could require the use of a service dog). I write novels about such people, including The Aremac Project, Aremac Power, Jigglers, First Stringers, Second Stringers, The Hands of God, Freshman Murders, Where There's a Will There's a Murder, Earth's Endless Effort, and Mistress of Molecules—all about how my brilliant protagonists produce quality work and learn to be happy. My books that are not yet on Leanpub may be found as eBooks at <http://www.smashwords.com/profile/view/JerryWeinberg>; on Amazon at http://www.amazon.com/-/e/B000AP8TZ8; and at Barnes and Noble bookstore: http://tinyurl.com/4eudqk5.

Early in my career, I was the architect for the Project Mercury's space tracking network and designer of the world's first multiprogrammed operating system. I won the Warnier Prize, the Stevens Award, and the first Software Testing Professionals' Luminary Award, all for my writing on software quality. I was also elected a charter member of the Computing Hall of Fame in San Diego and chosen for the University of Nebraska Hall of Fame.

But the "award" I'm most proud of is the book, The Gift of Time (Fiona Charles, ed.) written by my student and readers for my 75th birthday. Their stories make me feel that I've been at least partially successful at helping smart people be happy.

Bundles that include this book

Perfect Software
Are Your Lights On?
Handbook of Technical Reviews, Fourth Edition
General Systems Thinking
What Did You Say?  The Art of Giving and Receiving Feedback
8 Books
$83.92
Suggested Price
$49.99
Bundle Price

Table of Contents

    • PART A: Introduction
    • Introduction
    • About This Handbook
      • How Was the Handbook Developed?
      • Why Use Question and Answer Format?
      • Why Are You Ignoring My Favorite Form of Review?
      • How Can We Contribute New Questions, New Answers, or Corrections to the Handbook?
    • Why Do We Have Technical Reviews?
      • We already test our software. Isn’t that enough?
    • Just What Is a Technical Review?
      • Aren’t Reviews a Form of Communication?
      • Why Are Technical Reviews Different from the Budgetary and Scheduling Reviews Our Management Now Conducts?
      • Is There Any Difference Between These Formal Technical Reviews and the Progress Reports We Now Use?
      • Why Do You Call Them Formal Technical Reviews? Is There an Informal Review?
    • Just How Effective Are Reviews?
      • Can You Clarify the Responsibilities of the Review Group?
      • What If the Review Group Fails to Do This Job?
      • Isn’t the Level of Formality You Propose Unproductive?
      • The Review Process Appears to Reinforce the Tendency of Technicians to Want to Work in a Vacuum, in the Back Room, Behind Closed Doors.
      • Rather Than Adopt Consensus, Why Can’t Each Individual Reviewer Sign Off on the Product?
    • PART B: The Review Environment
    • How Many People Should Attend a Formal Review?
      • Is There Some Maximum Number of Attendees?
      • Is There a Minimum Number of People in a Review?
      • Why Not Just Pick Some Number, Like Five?
      • Is It Management’s Responsibility to Select Review Group Members?
      • How Can We Get People Under Different Managers to Attend?
      • Why Is It So Important to Us to Have These “Outsiders”?
    • What Are Some Other Ways to Break Down a Review That Is Too Big or Too Long?
      • How Can Anything Useful Be Done in a Short Two Hours?
      • But I Can Concentrate for Much More Than Two Hours
      • In Going Through the Handbook, I Didn’t See Any Mechanism to Buy In the User.
      • Support Groups (e.g., Systems Testing) Often Send People to Reviews. Should Such People Be Counted in the Limit?
      • Is There a Tendency for Companies to Use Outside Consultants for Reviewing, Rather Than Their Own People?
      • Does the Size of the Review Team Vary Significantly with the Product You Are Reviewing?
    • Are We Ready to Review?
      • What Happens If a Team or an Individual Producer Keeps Stalling the Scheduling of a Review?
      • How Can We Tell If Something Really Isn’t Ready for Review?
      • Why Not Just Set Up a Regular Schedule of Reviews Every Two Weeks (or Other Fixed Interval)?
    • Management Participation
      • Should Management Be Present at Formal Reviews?
      • What About Personality Conflicts?
      • How Can a Manager Learn About Formal Reviews Without Attending?
      • What About Having a Manager as Review Leader?
      • Isn’t It True That Under a System of Reviews, a Manager is No Longer Responsible?
      • That’s a Good Answer, but I Do Have Some Technical Competence, So Why Can’t I Have Input to the Evaluation Process?
    • Allocating Time and Facilities for Reviews
      • How Much Time Should We Plan on Spending on Formal Reviews?
      • How Does Project Size Affect Reviewing Time?
      • How Does Complexity of Material Affect Reviewing Time?
      • What Is Meant by “Closeness of Material to Finished Quality”?
      • Once This Stabilization Takes Place, How Does Review Time Depend on Closeness to Finished Quality?
      • What About the Time Taken to Review Rejected Material a Second Time?
      • What About Other Reasons for Multiple Reviews?
    • What If Facilities or People Are Limited?
      • We Don’t Have Many (Or Any) Places in Which Reviews Can Be Held. Have You Got Any Suggestions?
      • We Have Lots of Conference Rooms, but We Can’t Seem to Get All the Necessary People Free at the Same Time. What Do You Suggest?
      • We Have a Problem with Reviews Involving People from Several Departments.
      • The Relevant People for Some of Our Reviews Are Scattered All Over the Worid. Is It Possible to Conduct a Review by Telephone?
      • Telephone Meetings: A Tool for Inter-Center Communication
      • Preparation Before the Meetings
    • Notes on Getting Started
      • In Our Early Reviews, We Seem to Be Wasting a Lot of Time. Are Experienced, Competent Reviewers Able to Work Faster?
      • How, Then, Do We Allocate Time for Reviews When Planning Our Project?
      • We Can See That the Problem of Scheduling Becomes Less Acute with Time. But What About When We’re Starting Out?
      • What Is the Best Time to Set Aside for Reviews?
      • How Much Work Should Be Reviewed Initially?
      • Does This Apply to Formal and Informal Reviews?
      • What if Our Projects Don’t Come in That Size Piece?
      • Our Managers Have the Nasty Habit of Bumping Others out of Conference Rooms to Demonstrate Their Place in the Pecking Order. How Can We Prevent This Practice from Disrupting Our Reviews?
      • Of All the Things We Might Review, Which Is the Best to Start With?
      • Wouldn’t It Be Better to Start on Something That Isn’t an Actual Program, Like a Document or a Specification?
      • How About Reviewing this Handbook?
      • Can You Tell Us More About Using the Initial Reviews to Create Guidelines That Will Adapt This Handbook?
      • I’d Really Like to Get Started with Reviews, but I’m the Only Technical Person in My Shop, so What Can I Do?
      • We Are About To Become Involved in Structured Systems Development. Should We Give Our People a Chance to Become Familiar with These New Methodologies Before Starting Reviews in Addition?
      • But Won’t That Be Too Many New Things Going On at One Time?
      • So You Really Think We Should Start Reviews First?
      • We’re Still Not Satisfied with the Answers on Where to Start. With So Many Areas to Cover, Where Can We Start?
      • Would You Suggest Starting on One Completely New Project and Working with That, Rather Than Starting on a Particular Type of Review and Working on a Number of Projects at One Time?
      • Do You Need to Train People Formally in Doing Reviews, or Can You Simply Build Upon the Experience of Actually Doing Reviews?
      • How Long Do You Generally Find That It Takes for Your Clients to Get a Formal Review System Functioning at Full Capacity?
      • How Long Would It Take for the Practice to Penetrate the Entire Organization?
      • What About a Management That’s Not Committed One Way or the Other?
      • If Your Organization Is Carrying Out Fairly Successful Informal Team Reviews, How Do You Initially Justify the Expense of Formal Technical Reviews?
      • Are You Suggesting That Smaller Organizations Might Not Require the Full Spectrum of Formal Technical Reviews or That Smaller Organizations May Delete the Formal Review Altogether?
      • Doesn’t the Formal Review Create a Negative Learning Environment for the Producers?
      • Then Why Do You Emphasize Rules So Much?
    • Technical Reviews and Project Management
      • Are Technical Reviews a Form of Project Management?
      • We Paid a Lot of Money for the X System of Project Management. Just How Does This System Fit with Technical Reviews?
      • In Our Organization, Our Chief Programmer Teams Usually Produce Reliable Evaluations of the Quality of the Software They Are Producing. Why Do We Need Technical Reviews?
      • And You Say That Formal Technical Reviews Can Solve the Problem of Creating a Reliable Link to the Project Management System?
      • You Seem To Be Saying That the Review Is a Device for Tracking Progress. How Often Should We Hold Reviews, and How Does This Relate to Our System of Project Management?
      • You’ve Emphasized that We Should Review Early and Review Often. But Is It Possible to Do Too Much Reviewing?
      • What About the Total Number of Reviews Themselves?
      • Could We Reduce the Number of Reviews By Sampling—That Is, By Reviewing Only Randomly Selected Pieces of Work?
    • PART C: Conducting the Review
    • The Review Leader
      • What Are the Responsibilities of the Review Leader?
      • What Do You Mean, Report the Reasons a Good Review Wasn’t Obtained?
      • But What If the Product Being Reviewed Just Isn’t Very Good?
      • How Do We Choose a Review Leader?
      • But Aren’t Certain Mannerisms Always Fatal to a Review Leader’s Success?
      • Shouldn’t the Review Leader Be Someone Who Can Follow Through on Administrative Details Responsibly?
      • We Use Chief Programmer Teams. Shouldn’t the Review Leader Job Be Given to the Various Chiefs?
      • But Can Any Team Member Really Be Objective When Leading a Review of His or Her Team’s Work?
      • How Does the Review Leader Prepare for Each Review?
      • What Materials Are Needed in the Review Packet That the Leader Must Assemble?
      • Doesn’t That Involve a Great Deal of Copying Cost?
      • What Does the Review Leader Do During the Review Itself?
      • How Can the Review Leader Bring the Meeting Back to Order When It Drifts Into Irrelevant Subjects?
      • But What About Someone Who’s Really Just Being Obstructive and Noncooperative in the Review?
      • What About the Really Quiet Person Who Just Hasn’t the Nerve to Speak Up?
      • How Can the Leader Be Sure the Review Covers All the Important Points?
      • We’ve Seen a Tendency for Some Impatient Persons to Rush Through the Review and Produce Superficial Comments. What Can the Leader Do About This?
      • Some People Find It Hard to Say Bad Things About Someone Else’s Work. How Can the Review Leader Encourage Them to Contribute?
      • We Have One Person Who’s Always Late for the Review. Should We Wait for This Person or Start the Meeting Anyway?
      • But Sometimes There’s a Good Reason for a Person to Be, Say, Fifteen Minutes Late. Isn’t This a Rather Severe Procedure?
      • Our Problem Is Just the Opposite. What Can We Do About a Person Who Always Leaves Early?
      • Do You Have Any Good Ideas How to Handle the Person Who Tends to Want to Redesign, Rather Than Raise Issues?
      • Is There Any Special Way the Leader Should Start the Review?
      • Shouldn’t the Leader Ask If Everyone Is Prepared?
      • Then How Can the Leader Discover If People Are Not Prepared for the Review?
      • Why Is It So Important If One Person Out of Five or Six Isn’t Prepared?
      • Why Not, Then, Invite a Few Extra People, Knowing That It’s Just Human Nature for a Few of Them Not to Be Prepared?
      • How Do You Use This Consolidated Checksheet?
      • What Can I Do to Ensure Full and Relevant Participation?
      • If You Asked People, at the Outset, What They Felt Was Missing from the Material Reviewed, Wouldn’t That Give You a Good Idea If Someone Wasn’t Prepared?
      • Review Leaders Find It Too Hard to Actually Stop the Review Because One Person Isn’t Prepared. What Should We Do?
      • But Suppose John and Mary Have a Legitimate Excuse for Not Being Prepared. Do You Want the Review Committee to Act as Ratfinks?
      • What About When the Unprepared Person Comes from a Different Department and Reports Not to Your Management but to Someone Else? Do You Have Any Experience with That?
      • Yes, but How Can the Review Leader Bring the Meeting to a Close?
    • The Recorder
      • What Are the Responsibilities of the Recorder?
      • What Is the Most Common Way of Carrying Out the Recorder’s Responsibilities?
      • Our Company Doesn’t Like Flip Charts. Do We Really Need to Use Flip Charts?
      • Are There Any Other Recording Methods in Common Use?
      • What About Videorecording the Meeting, so No Recorder Is Needed?
      • Who Should We Select as Recorder?
      • Why Not Have the Leader Act as Recorder?
      • We Use a Program Librarian, Whose Functions Are More or Less Those Described by Harlan Mills of IBM. Is It a Good Idea to Use the Librarian as Recorder?
      • But What if We Don’t Have a Librarian?
      • Can More Than One Person Be Recorder in the Same Review?
      • Are There Any Other New Ideas About the Recorder Task You’ve Learned About Since the First Edition of the Handbook?
      • We Have Started Using an Audio Recorder to Collect the Points Raised and Agreed Upon, Rather Than the Entire Proceedings of the Meeting. How Do You Feel About It?
      • How Should the Recorder Be Placed Physically with Respect to the Other Members of the Review Group?
      • Speaking of Flow of the Meeting, We Often Find That the Recording Is Slowing Things Down and Draining the Energy of the Review. What Can We Do About This?
      • When I’ve Acted as Recorder, I’ve Had Trouble Making My Own Points, so I Feel It’s Been a Waste to Prepare. Any Suggestions?
      • Have There Been Any Attempts to Automate the Review Recording Process?
      • A Checklist for Recorders
    • Helpful Rules and Customs for Reviewers
      • How Can I, as a Participant with No Special Role, Make Certain That the Review Runs Correctly?
      • Rule I: Be Prepared
      • Rule II: Be Willing to Associate
      • Rule III: Watch Your Language
      • Rule IV: One Positive—One Negative Comment
      • Rule V: Raise Issues, Don’t Resolve Tiiem
      • Rule VI: Avoid Discussions of Style
      • Rule VII: Stick to Standard—Or Stick the Standard
      • Rule VIII: Only Technically Competent People Participate in Reviews
      • Rule IX: Record All Issues in Public
      • Rule X: Stick to Technical Issues
      • Rule XI: Remember Education
      • Rule XII: Do Not Evaluate the Producers
      • Rule XIII: Distribute the Report as Soon as Possible
      • Rule XIV: Let the Producers Determine When the Product Is Ready for Review
      • Summary of Helpful Rules and Customs
    • Helpful Rules for Management
      • Since They Can’t (Usually) Attend Reviews, How Can Managers Participate in the Review Process?
      • Rule I: Show a Commitment to the Review Process
      • Rule II: Budget Time for the Review Process
      • Rule III: Be Prepared to Assign Real People to the Review Task
      • Rule IV: Encourage the Participants to Prepare
      • Rule V: Help Out with the Physical Arrangements
      • Rule VI: Don’t Be Penny Wise and Pound Foolish
      • Rule VII: Reward Good Reviews of Bad Products
      • Rule VIII: Punish Poor Reviews of Any Product
      • Rule IX: Punish Poor Review Behavior
      • Rule X: Override a Review Judgment Only at Your Peril
      • Summary of Helpful Rules for Management
    • The User As Reviewer
      • As a User, What Do I Do if I Don’t Understand What I Am Reviewing?
      • We Find That the Programmers Want Us as Users to Review the Code. We Don’t Understand Code.
      • Does That Mean That If Anything Is Presented That I Don’t Understand, Then I Shouldn’t Be There?
    • PART D Reporting the Results of the Review
    • Functions of Reporting
      • What Is the Major Reporting Function of the Review?
      • Why Is This Function So Fundamental?
      • How Does the Review Report Solve These Crisis Problems?
      • Are Review Reports Always That Accurate?
      • How Does the Historical Record Help Evaluate the Review Process?
      • Does Historical Analysis Provide Specific Information to Show How the Review Process Can Be Improved?
      • Our Problem Has Always Been the Inability to Know When Some Phase of a Project Is Actually Complete.
      • What Are Some of the Other Benefits of the Historical Record of Reviews?
      • What Do the Producers Get Out Of Submitting to This Procedure?
      • Do Other Technical People Benefit from the Review Reports?
      • What Are the Various Reports Issued by the Review?
    • The Technical Review Summary Report
      • What Information Goes on the Summary Report?
      • Why Is It Necessary to Have the Individual Reviewers’ Signatures?
      • Why Single Out the Review Leader and Possibly the Recorder for Special Notice and Mention?
      • Can You Explain What It Means for the Review Group to Accept the Work Unit?
      • What About a Decision to Rebuild?
      • How Is the Decision to Rebuild Made?
      • If One Person Dictates a Rebuild Decision, Won’t That Lead to Irresponsible Behavior?
      • What Is the Difference Between Major and Minor Revisions?
      • Are There Any Other Decision Possibilities for the Review?
      • Are There Any More Decision Possibilities?
      • Can You Explain the Consensus Idea a Bit More?
      • What Happens If the Committee Cannot Even Agree to Accept the Doubts of the Most Doubting Member?
      • What Should We Do If We Can’t Agree If the Product Needs Major Revision or Rework?
      • Is a Design Bad or Is the Document Describing the Design Bad? How Do We Decide?
    • The Technical Review Issues List
      • What Is the Purpose of the Issues List?
      • Does Management Get a Copy of the Issues List?
      • What Form Should the Issues List Take?
      • What Form Should We Use If We Intend to Classify the Issues for Research Purposes?
      • Is It Ever Permitted to Record Positive Comments?
      • Could We Have an Extra Report, Unofficially Giving Positive Points?
      • How About Conducting a “Positive Comments” Review, in Addition to the Main Review?
      • Does Everyone Have to Agree About an Issue Before It Goes on the Issues List?
      • When the Issue Is Not Agreed Upon Unanimously, Should That Fact Be Noted?
      • Should the Review Leader Decide What Appears on the Issues List?
      • When a Product Is Rejected With Major Issues, What Should Be Done with the Minor Issues?
      • Couldn’t the Producers Learn Good Techniques from Minor Issues, Even If the Code Is Discarded?
      • Are You Implying That the Committee Need Not Report All Issues in All Cases?
      • Won’t Reviewers Feel Frustrated and Angry If Their Points Are Not Captured?
    • The Technical Review Related Issues Report
      • Do You Recommend a Special Form for Reporting Related Issues?
      • Do the Related Issues Become Part of the Work’s Documentation?
      • Who Should Be Responsible for Preparing a Related Issues Report?
      • I Thought the Review Committee Had to Agree by Consensus?
      • Can Anyone Who Wishes Write a Related Issues Report?
    • System History File
      • What Is the System History File?
      • How Long Should We Keep the System History File?
      • Can’t the System History Be Used to Check Up on a Person’s Performance?
      • Won’t That Be Just As Inhibiting As a Manager Sitting in the Review?
      • Can You Recommend Any Regular Reports That Can Be Extracted from the System History?
      • The Agile Manifesto Recommends Tuning of Team Performance. Can the System History Be Used to Help Tune?
      • Or perhaps the specification writing is so poor that major problems turn up in almost every attempt?
      • Any Other Reports?
    • Issues
      • You’ve Said “Don’t Count Issues,” but Can Useful Information Be Extracted from the Issues Lists?
      • Can You Give Us Some Guidelines for Writing Issues Clearly and Without Bias?
      • A Test that Takes Issues with Issues
      • A list of issues with issues
      • Explanations of Test Issues
    • PART E: Varieties of Review Disciplines
    • Why So Many Review Variations?
      • Why Do So Many Different People Use So Many Different Variations on the Technical Review Idea?
      • What Are the Most Common Variations of the Format Technical Review as You’ve Described It?
      • Since Your First Edition, What Has Changed In Your Thinking About Review Disciplines?
    • Quick Reviews
      • Don’t You Think Reviews Take Too Long?
    • Walkthroughs
      • What Is a Walkthrough?
      • What Is the Difference Between a Structured Walkthrough and Any Other Walkthrough?
      • What Are the Advantages of the Walkthrough?
      • It Sounds as If the Walkthrough Might Be Very Useful to Us in Some Situations. What Else Can You Tell About the Way It Is Conducted?
      • What Are Some Problems with the Walkthrough, in Practice?
      • Doesn’t the Presenter’s Ego Get in the Way of a Proper Evaluation?
      • Well, Enough of Advantages and Disadvantages! Do You Recommend Walkthroughs or Don’t You?
      • Aw, Come On! Give Us a Real Yes or No!
    • Inspections
      • Are You Implying That Inspections Are Used Only for High Level Pieces of Work?
      • How Is the Inspection Conducted?
      • What Kind of Report Does an Inspection Generate?
      • What Is the Role of the Leader in an Inspection?
    • Round-Robin Reviews
      • What Is a Round-Robin Review?
      • What Are the Advantages of This Approach?
      • Can You Give an Example of a Round-Robin Review?
      • What Is a Worst-First Review?
      • What Are Some Other Round-Robin Variations?
      • Isn’t It a Disadvantage of Round-Robin Reviews That a Single Person Is Responsible for One Part, Functional or Otherwise?
      • What Are Some Other Forms of Redundant Round Robins?
      • It All Sounds Rather Chaotic. How Can It Be Kept Under Control?
      • Why Not Just Do the Round-Robin by Circulating the Review Material to Each Reviewer, Who Then Reviews the Product On Their Own Time, in Their Own Office?
    • Review Teams
      • What Is the Distinction Between a Review Committee and a Review Team?
      • Is a Quality Assurance Group an Example of a Review Team ?
      • What Are the Advantages and Disadvantages to Having a Permanent Team Devoted Solely to Reviews?
      • Then What About Users Acting as Reviewers?
      • Yes, But What If Our Customer Is a Government Agency, with Its Own Technical People Who Must Review?
      • Our Client Will Take Over Software Maintenance After We Deliver. Doesn’t That Give Them the Right to Review How It Is Done?
      • We Can’t Do That with Our Customer, Yet They Insist on Reviewing Our Technical Work. What Do You Suggest?
      • Yet Elsewhere in This Handbook You Recommend Reading the Code from Purchased Software. Doesn’t That Make You the User on the Other Side of the Fence?
      • If Your Opinion Is Correct, Then How Can We Have Review Teams?
      • Can You Give an Example of Such “Part-Time” Review Teams?
    • A Collection of Review Tactics
      • What Do You Mean by a Review Tactic?
      • The Devil’s Advocate
      • Bebugging
      • The Money Bowl
      • The Alarm
      • Issues List Bloodhound
      • The Stand-up Review
      • Tables?
    • Informal Reviews
      • Is There Ever an Advantage to Reviewing Code Informally, Rather Than Going Through All These Procedures?
      • How Are Informal Reviews Conducted?
      • Informal Reviews Sound Like a Good Idea for Our Installation, but Should We Start Them Before or After Formal Reviews?
      • What Should We Look For in Informal Reviews?
      • Do You Mean That the Informal Review Is Pretty Much a Rehearsal for the Formal Review?
      • Then What’s the Real Difference Between Them?
    • PART F: Types of Materials Reviewed
    • Varieties of Reviews and Their Origins
      • We’ve Heard About Code Reviews, but Are There Other Materials That Can or Should Be Reviewed?
      • After Design and Specification Reviews, Are There Further Stages in the Review Process?
      • We Write Code in a High Level Language. Do We Have to Review the Object Code as Well as the Source Code?
      • What Role Do Test Data Play in Each of These Reviews?
      • So Far, All You Have Discussed Is Reviewing Products Directly Connected with the System. Are There Other Items That Should Be Reviewed?
      • What About Products That Are Not for Human Consumption, Like Code That Controls an Automated Factory?
      • Yes, But Even Educational Products Are Products. Are There Nonproducts That Are Reviewed?
      • Do You Consider Standards to Be Products, and Therefore Reviewable?
      • How About Software Packages We Buy from Outside Vendors?
      • I Think I’m Beginning to Get the Idea—Just About Anything Can Be Reviewed.
      • Can You Give Further Examples of the Distinction Between Technical and Management Reviews?
      • Aren’t There Some Areas in Which It’s Difficult to Separate Management (Value) Issues from Technical (Factual) Issues?
    • Specification Review
      • Why Are Specification Reviews Necessary, Since Our Analysts Are Very Experienced at Writing Specifications?
      • Who Should Participate in a Specification Review?
      • Systems We Develop Have Multiple Users, with Different and Sometimes Contradictory Points of View About What the System Should Do. Who Gets Invited to the Review?
      • That Seems Reasonably Clear, but You Still Haven’t Said Who Gets Invited.
      • I’m Not Sure I Understand What You Mean by a “User” or by a “User Faction.” Can You Elaborate?
      • How Do You Identify All the Users and User Factions?
      • Well, I Agree It’s a Fine Idea to Get the Users Involved in Reviews, but How Can We Get Our Users to Cooperate and Communicate with One Another?
      • What About the User Who Wants to Institute Changes When the Specification Is Reviewed?
      • If We Allow Our Users the Opportunity, How Can We Stop Them From Making Unending Changes?
      • Our Users Would Like to Get Involved in Reviewing Specifications, but They Have No Common Language with the Producers. What Can We Do?
      • What Specifically Should the Specification Review Committee Look for in a Specification?
      • The BCS Requirements Checklist
      • Can Any of These General Headings Be Further Refined into More Detailed Checklists?
      • Can You Give Us Any Checklists for Specification Checking?
      • Ambiguous Keyword Examples
      • Some Methods of Transforming Specifications to Reveal Ambiguities, Errors, and/or Misunderstandings
    • Design Reviews
      • How Important Are Design Reviews? Aren’t Most Errors in the Code, Rather Than in the Design?
      • Which Design Level Is the Better Choice for Reviews?
      • What About Reviewing Logical vs. Physical Design?
      • How You Can Review Designs? Isn’t Correct or Incorrect a Matter of Opinion with Designs?
      • Is It Possible, Then, to Develop Checklists for Design Reviews?
      • The BCS Preliminary Design Document Review Checklist
      • The IBM Detail Design Report
      • Design Misfit Checklist
      • Can We Use a Design Review to Compare Two or More Contending Designs?
      • Do You Mean That One Design Review Should Be Restricted to Reviewing One Design?
      • What Form Should This Design/Spec Statement Take?
      • Do You Choose the Design with the Highest Score?
    • Code Reviews
      • Why Has the Code Review Received So Much Attention in the Literature? Is It More Important Than the Other Kinds of Review?
      • Then You Think Code Reviews Aren’t the Ideal Place to Start, If We’re Just Instituting Reviews for the First Time?
      • But Won’t All That Pain Put Too Much Pressure on the Early Reviews?
      • What Do You Mean by “Bringing These Facts into the Open”?
      • But Why All This Emphasis on Error?
      • We Lack Historical Data on Errors. Would It Be a Good Idea To Go Back in Time and Accumulate Some?
      • How About Counting the Errors Found in the Reviews?
      • How Can We Feed Back Educational Information If We Don’t Count and Classify Errors in the Code?
      • Can You Give Us Some Guidelines for Reviewing Code?
      • General Questions to Keep in Mind When Reviewing Code
      • Those Questions Seem Very Broad. Can They Lead to an Adequate Review?
      • We Did a Terrific Formal Code Review. Unfortunately, Our Management Wasn’t Interested in the Report. What Should We Do?
      • Program Checklists
      • Summary of Rules from Kernighan and Plauger
    • Documentation Reviews
      • We Have a Staff of Proofreaders Who Read Our Documentation Before It Goes Into Final Printing. Is That an Alternative to Reviews?
      • Just What Do You Consider “Documentation” for Purposes of Documentation Review?
      • Would That Include User Documentation?
      • But Just How Important Is User Documentation Anyway, as Long as the System Itself Works Properly and Is Properly Documented?
      • Who Should Be Involved in the User Documentation Review?
      • Do the Producers Have to Get Involved in Documentation Reviews?
      • What Do You Look for in Reviewing User Documentation?
      • But It’s Really Impossible for Us to Test Our Documentation Before a Review. Isn’t There Some Other Approach?
      • Are Error Messages Part of User Documentation?
      • Is There Some Sort of Checklist for Reviewing Documentation?
      • Are There Automatic Tests for Quality of Documentation?
      • Can These Methods Be Used in Place of Documentation Reviews?
      • I’m Sure That the “Astronomical” Number of Errors in (the First Edition of) this Handbook Was Intentional (Bebugging?); But if Not, You Had Better Review Your Own Work, Hadn’t You?
      • Is It Really Necessary to Make a Separate Review Report for Each and Every Page, Just for Proofreading?
    • Test Plan Reviews
      • Why Isn’t a Test Plan Review Simply Part of the Functional Specification Review?
      • Why Isn’t the Test Plan Review Part of the Code Review, Since the Code Will Have Been Run Against the Planned Tests?
      • But Doesn’t the Code Tend to “Track” the Test Plan?
      • I Don’t Agree with the Idea That Tests Can Be Made Up Before the Code Is Complete.
      • What Should a Test Plan Consist Of?
      • Why Are You Making What Seems to Be a Rather Artificial Distinction Between Environment and Other Input and Output?
      • Who Else Should Be Invited to Test Plan Reviews?
      • System Testing Laundry List
    • Tool and Package Reviews
      • Should We, as Consumers of Software Packages, Review Them After We Buy Them?
      • Some of the Software We Purchase Doesn’t Have User’s Manuals, So How Can We Review Them?
      • Isn’t It Enough Just to Review the User Documentation, Rather Than to Delve into the Innards of the Software?
      • What If We Have an Ironclad Maintenance Agreement?
      • Yes, But Our Vendor Simply Will Not Let Us Examine the Insides of the Software, to Protect Their Investment. What Can We Do Then?
      • It Would Be Very Difficult for Us to Review Our Vendor’s Software Because It’s Written in a Language We Don’t Use. What Can We Do Then?
      • It Seems to Me to Be an Awful Lot of Trouble. It’s Also Potentially Insulting to Someone Who Offers to Give You Some Piece of Software Free.
      • I Can See the Value of Reviewing Purchased Tools and Packages, but I Anticipate Difficulty Selling the Idea Around Here Because Everyone Is So Busy. Any Ideas?
      • What Should We Look For in Reviewing a Software Package or Tool?
      • Does That Mean We Have to Go Through Specification Reviews, Design Reviews, Code Reviews, and the Whole Ball of Wax?
    • Reviews of Training Materials and Plans
      • In What Sense Are Training Materials Reviewable?
      • Who Should Participate in Reviews of Training Materials?
      • What Should We Look For Besides Accuracy in Training Materials?
      • What If There Are No Instructors—As in the Case of Self-Teaching Materials?
      • Do You Have Other Checklists for Educational Materials?
      • What About Checking the Facilities and Equipment for a Course?
    • Standards Reviews
      • Why Review Procedures and Standards?
      • What’s So Bad About Not Following Standards?
      • Isn’t It Better to Look for Standards Violations When Reviewing Code?
      • What Should We Look For in Reviewing Standards?
      • We Have a Permanent Standards Organization Consisting of Four People Full Time. Shouldn’t They Be Doing This Review of Standards?
    • Operations and Maintenance Reviews
      • Why Are Reviews Required of Systems Already in Production, Since Changes There are Usually Minor in Size and Complexity?
      • But How Can Reviews Help Out in This Situation, When We Already Lack Adequate Time to Make Maintenance Changes?
      • What Do We Look For in a Maintenance Review?
      • How About a Checklist for Potential Side Effects of a Maintenance Change?
      • If We Start Reviewing Our Old Code, Won’t Our Maintenance Programmers Become Aware of How Bad It Really Is, Thus Leading to a Revolt?
      • In What Ways Can Reviews Help Correct the Poor Situation We’ve Gotten Into Over Many Years of Nonreviewed Maintenance?
      • What’s a Fix-and-Improve Review?
      • Doesn’t It Cost a Lot of Time and Effort to Make These Improvements? We Can See That the Fix-and-Improve Strategy Might Eventually Pay Off, But We Really Can’t Afford to Increase Present Maintenance Costs.
      • What Is Meant by a Separation of Production and Maintenance Acceptance Reviews?
      • Won’t Our Maintenance People Will Reject All Work, Just to Make Their Jobs Easier?
      • How Can We Tell Management What the Costs of Maintenance Are Going to Be?
      • Those Questions Seem Awfully Subjective to Me. How Much Faith Can Be Placed in the Answers the Review Committee Comes Up With?
      • Should Operations People Be Involved in Maintenance Reviews?
      • What Other Roles Do Operations People Play in Reviews?
      • What Sort of History Information Does Operations Feed Back Into the Review Process?
      • How Does Operations Initiate a Review of an Existing Product?
      • You Haven’t Mentioned Anything About Postimplementation Reviews Except When Things Go Wrong. Can You Have Regularly Scheduled Postimplementation Reviews?
      • Do You Continue on a Three-Month Interval?
    • Reviews in an Academic Environment
      • Implementation of Structured Walkthroughs in the Classroom
    • Other Books by Jerry Weinberg
    • About the Author
  • PART G: Bibliography

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors, publishers and universities use Leanpub to publish amazing in-progress and completed books and courses, just like this one. You can use Leanpub to write, publish and sell your book or course as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub