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:
- plan their work,
- do their work according to this plan,
- 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]:
- Define the quality goal
- Measure product quality
- Understand the process
- Adjust the process
- Use the adjusted process
- Measure the result
- Compare the results with the goal
- Recycle and continue improving [at 4]
Ch.2 Time Management
- p.9-10
- The logical basis for time management is as follows.
- You will likely spend your time this week much the same way you spent time last
week.
- To make realistic plans, you have to track the way you spend time.
- To check the accuracy of your time estimates and plans, you must document them
and later compare them with what you actually do.
- To make more accurate plans, determine where your previous plans were in error
and what you could have done better.
- To manage your time, plan your time and then follow the plan.
- p.11
- To practice time management, the first step is to understand how you now spend time.
This calls for several steps:
- Categorize your major activities.
- Record the time spent on each major activity.
- Record time in a standard way [cf. Time Recording Log].
- Keep the time data in a convenient place [cf. engineering notebook].
- 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:
- Date, start, stop, interruption time, delta time, activity,
comments, C(ompleted) , U(nits).
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:
- the size and important features of the product to be produced,
- an estimate of the time required to do the work,
- a projection of the schedule.
- 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:
- what will be done,
- the criteria for determining that it is done,
- who will do it,
- when it will be done,
- the compensation or other consideration to be given in return,
- and who will provide this compensation or consideration.
- p.89
- You can make sure your commitments are responsible and well managed as follows.
- Analyze the job before agreeing to the commitment.
- Support the commitment with a plan.
- Document the agreement. ...
Even after two people orally agree, they often have trouble agreeing on a written
statement of the agreement. ...
[W]hat parties will do in the event of problems ...
is the principal reason for most contracts.
- If unable to meet the commitment, promptly tell the other party and try to
minimize the impact on that person.
- 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:
- Make a list of your current commitments,
- include what is to be done and when, and
- 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. ...
- The first tool that engineers use is a compiler. ...
- A second way to find defects is through testing. ...
- The third way ... is to ship defective programs and wait for the users to identify
and report the defects. ...
- Finally, the most effective way to find and fix defects is by
personally reviewing the souce program listing [called a code review].
While this may seem like a difficult way to clean up a defective program,
it turns out to be fastest and most efficient.
- p.163
- [I]t is important that you use the following practices when you review code:
- Do the review before the first compile.
- Do the review on a printed source code listing.
- Record every defect found in the Defect Recording Log.
- During the reviews, check for the types of defects you have previously found in
compile and test.
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
- p. 110
Brooks, Frederick P., Jr.
The Mythical Man-Month: Essays on Software Engineering.
Addison-Wesley, 1972 (Anniversary Edition 1995).
- p. 237
Gries, David.
The Science of Programming.
Springer-Verlag, 1981.
- pp. 121, 155, 174, 224, 251
Humphrey, Watts S.
Managing the Software Process.
Addison-Wesley, 1989.
- pp. 110, 121, 136, 155, 207
Humphrey, Watts S.
A Discipline for Software Engineering.
Addison-Wesley, 1995.
- pp. 8, 273
Leveson, Nancy G.
Safeware, System Safety and Computers.
Addison-Wesley, 1995.