Humphrey on the Personal Software Process

Selected quotes from
Watts S. Humphrey.
Introduction to the Personal Software Process.
Addison-Wesley, 1997.
compiled by Tom Verhoeff. Bold face emphasis is somtimes mine.

Reading these quotes is no substitute for reading the book and doing the exercises. In fact, I hope that these quotes will make you more interested in the material.

Ch.1 The Software Engineer's Job

p.1
The job of a software engineer is to deliver high-quality software products at agreed cost and schedule. ... [Software engineers] need to:
  1. plan their work,
  2. do their work according to this plan,
  3. and strive to produce the highest quality products.
The principal objective of this book is to show you how to do this.

p.3
Professionals in many other fields learn and practice the skills and methods of their professions during their formal education. ... [I]n other fields, professionals demonstrate basic competence before they are permitted to do even the simplest procedures, while in software, engineers ... must learn the skills they need on the job.

p.5-6
The improvement process is charted [as follows]:
  1. Define the quality goal
  2. Measure product quality
  3. Understand the process
  4. Adjust the process
  5. Use the adjusted process
  6. Measure the result
  7. Compare the results with the goal
  8. Recycle and continue improving [at 4]

Ch.2 Time Management

p.9-10
The logical basis for time management is as follows.

p.11
To practice time management, the first step is to understand how you now spend time. This calls for several steps:

p.12
As a ... professional, you will ... have many uses for an engineering notebook, such as keeping a time log, entering calculations, and making design notes. You could even use it as evidence that you followed sound engineering practices ...

Ch. 3 Tracking Time

p.20
The format and procedure used to gather the [time] data are not important as long as the data are accurate and complete.

p.21
The typical amount of uninterrupted time engineers spend on tasks is generally less than an hour. ... [T]rack time in minutes ...

p.22
Use a Standard Time Recording Log. ... Each time period is entered on one line of the form as follows: Delta time[:] The time spent on the activity, in minutes, between the start and stop times, less any interruption time.

p.25
One common problem with tracking time is interruptions. ... One trick that I have found useful is to use a stopwatch for tracking interruptions. ... Since interruption time is not productive job time, you must track interruptions. ... Time log data can also be used to understand how often your work is interrupted.

p.28
Another approach is to record the time data on a computer. I have tried this and found it took more time and was less convenient than making notes on paper.

Ch.4 Period and Product Planning

p.31
There are two kinds of planning. The first is based on a period of time, any calendar segment ... A period plan concerns the way you plan to spend time during this period. The second kind of plan is based on an activity [or product]...

p.33
Since the time logs are far too detailed for [period] planning purposes, you need to summarize data in a more useful form. [e.g.] the Weekly Activity Summary ...

p.43
Eventually you can stop summarizing time every week and just make a summary when your time distribution changes or you may ultimately find it adequate to summarize time on a monthly basis.

Ch.5 Product Planning

p.47
A properly produced product plan includes three things:

p.48
The most basic product plan would consist of only the estimate of time needed to do a task or job. Once you can accurately estimate the time to do a job, all the other planning questions can usually be handled rather easily. ...

The Job Number Log is designed to record estimated and actual time data. [It] is a product planning document ... [T]he Time Recording Log and Weekly Activity Summary ... are ... period planning documents.

Ch.6 Product Size

p.58
Since tasks often vary considerably in size and complexity, it would be helpful to have a way to compare their sizes.

p.59
While [the] use of size measures seems simple enough, there are some complications. ... To handle such issues, you should keep separate size and time records for the different kinds of work you do.

p.66
There are no methods that guarantee a good size estimate.

[E]nter the size data in the Time [Recording] Log.

Ch.7 Managing Your Time

p.75
The time budget is your plan for how to spend time.

p.77
The key to time management is to gradually balance the way you spend time. ... People often waste a lot of time deciding what to do next. ... [A] time budget will enable you to know what to do next.

p.81
One essential step in time management is establishing priorities.

p.85
A rule to live by in software engineering is this: Do not throw away old plans, data, or programs. Surprisingly often, you will need them later.

Ch.8 Managing Commitments

p.88
A true commitment is both personal and contractual and it requires an explicit and voluntary agreement between two or more parties on:

p.89
You can make sure your commitments are responsible and well managed as follows.

p.93
Don't give up without seriously trying to meet the commitment. Have you checked with an independent expert ...?

The principal reason to manage your commitments is so you don't overlook or forget any.

p.94
When overcommitted, people often set priorities based on what must be done first rather than what is most important.

The most important single asset a software engineer can have is a reputation for meeting commitments.

p.96
The steps to managing commitments are:
  1. Make a list of your current commitments,
  2. include what is to be done and when, and
  3. include an estimate of how much work each commitment will likely take.

Ch.9 Managing Schedules

p.97
You make schedules to meet commitments.

p.98
A schedule is a time-ordered listing of planned events, generally in a format like ... a Gantt Chart.

p.101
A checkpoint is an objectively identifiable point in a project.

p.108
You should have a checkpoint for at least every 5 to 10 hours of work, and at least one or two checkpoints for every project week.

Ch.10 The Project Plan

p.111
The project plan defines the work and how it will be done. It provides a definition of each major task, an estimate of the time and resources required, and a framework for management review and control. ... [Humprhey 1989]

Ch.11 The Software Development Process

p.123
In helping a number of organizations improve their performance, one of the principle problems I have found is determining the organization's current performance.

A process is a defined set of steps for doing a job.

p.124
When a process is fully described, it is called a defined process. Defined processes are typically composed of scripts, forms, templates, and standards. A process script is a written set of steps the process users or agents follow when using the process.

Ch.12 Defects

p.138
[W]hile there are many aspects to software quality, your first quality concern must necessarily be with its defects. ... [E]ven experienced programmers typically make a mistake for every seven to ten lines of code they develop.

p.139
A defect ... is anything that detracts from the program's ability to completely and effectively meet the user's needs. ... It is something you can identify, describe, and count.

The sophistication of the ... mistake and the impact of the resulting defect are ... largely independent.

It is important to separate the question of finding or identifying defects from determining their causes.

When engineers make errors that result in defects, we refer to this as injecting defects.

p.140
Because testing time is hard to predict, defects are often a major cause of cost and schedule problems.

Some people mistakenly refer to software defects as bugs. When called bugs, they seem like pesky things that should be swathed or even ignored. This trivializes a criticial problem and fosters the wrong attitude. ... Defects are more like time bombs than bugs.

p.141
In analyzing defects, it is helpful to divide them into categories.

Ch.13 Finding Defects

p.158-159
Although there is no way to stop injecting defects, it is possible to find and remove almost all defects early in development. ... There are various ways to find the defects in a program. ...

p.163
[I]t is important that you use the following practices when you review code:

Ch.14 The Code Review Checklist

p.176
When it is necessary to find and correct every defect in a program, you must follow a precise procedure. A checklist can help ensure that procedure is followed.

Ch.15 Projecting Defects

Ch.16 The Economics of Defect Removal

p.209-210
In spite of many years of technological advances in the computer field, the work of software engineers has not appreciably changed in over 30 years. Software engineers have always broken big programs into smaller parts. They then generally work by themselves to develop one or more of these parts. In the process, they spend 30-40% or more of their time trying to get these programs to run some basic tests. ... The process of integrating and testing is almost totally devoted to finding and fixing more defects. ... [Q]uality is often so poor that the engineers must spend many more months fixing the defects the customers report.

There are better ways to develop software. The basic problem is that when software engineers first write their programs, they typically rush through the design and coding so they can get their programs into the compile and test phases. A principle of quality work, however, is to build the product right the first time.

p.211
Students and engineers typically inject 1 to 3 defects per hour during design and 5 to 8 defects when writing code. They only remove about 2 to 4 defects per hour in testing but find 6 to 12 defects per hour during code review.

Ch.17 Design Defects

Ch.18 Product Quality

Ch.19 Process Quality

Ch.20 A Personal Commitment to Quality

References