debugging: Updates and wordsmithing, take one

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

1 files changed, 52 insertions, 44 deletions

diff --git a/debugging/debugging.tex b/debugging/debugging.tex
index 5c9e90e8..c9cae11b 100644
--- a/debugging/debugging.tex
+++ b/debugging/debugging.tex
@@ -13,26 +13,24 @@ And I have had far more parallel programs that fooled me into thinking
 that they were working correctly the first time than actually were working
 the first time.
 
-I have therefore had great need of validation for my parallel programs.
-The basic trick behind parallel validation, as with other software
-validation, is to realize that the computer knows what is wrong.
+I thus need to validate my parallel programs.
+The basic trick behind validation, is to realize that the computer knows
+what is wrong.
 It is therefore your job to force it to tell you.
 This chapter can therefore be thought of as a short course in
-machine interrogation.\footnote{
-	But you can leave the thumbscrews and waterboards at home.
-	This chapter covers much more sophisticated and effective
-	methods, especially given that most computer
-	systems neither feel pain nor fear drowning.
-	At least as far as we know.}
+machine interrogation.
+But you can leave the good-cop/bad-cop routine at home.
+This chapter covers much more sophisticated and effective methods,
+especially given that most computers couldn't tell a good cop from a
+bad cop, at least as far as we know.
 
 A longer course may be found in many recent books on validation, as
-well as at least one rather old but quite worthwhile
+well as at least one older but valuable
 one~\cite{GlenfordJMyers1979}.
 Validation is an extremely important topic that cuts across all forms
-of software, and is therefore worth intensive study in its own right.
-However, this book is primarily about concurrency, so this chapter
-will necessarily do little more than scratch the surface of this
-critically important topic.
+of software, and is worth intensive study in its own right.
+However, this book is primarily about concurrency, so this chapter will do
+little more than scratch the surface of this critically important topic.
 
 Section~\ref{sec:debugging:Introduction}
 introduces the philosophy of debugging.
@@ -55,8 +53,9 @@ Finally,
 Section~\ref{sec:debugging:Summary}
 gives a fanciful summary and a short list of statistical traps to avoid.
 
-But never forget that the two best debugging tools are a solid design
-and a good night's sleep!
+But never forget that the two best debugging tools are a thorough
+understanding of the requirements, a solid design and a good night's
+sleep!
 
 \section{Introduction}
 \label{sec:debugging:Introduction}
@@ -87,13 +86,13 @@ Because of this history, the following three characteristics of computers
 often come as a shock to human intuition:
 
 \begin{enumerate}
-\item	Computers typically lack common sense, despite decades of research
-	sacrificed at the altar of artificial intelligence.
-\item	Computers generally fail to understand user intent, or more
-	formally, computers generally lack a theory of mind.
-\item	Computers usually cannot do anything useful with a fragmentary plan,
-	instead requiring that each and every detail of each and every
-	possible scenario be spelled out in full.
+\item	Computers lack common sense, despite huge sacrifices at the
+	altar of artificial intelligence.
+\item	Computers fail to understand user intent, or more formally,
+	computers generally lack a theory of mind.
+\item	Computers cannot do anything useful with a fragmentary plan,
+	instead requiring that every detail of all possible scenarios
+	be spelled out in full.
 \end{enumerate}
 
 The first two points should be uncontroversial, as they are illustrated
@@ -102,8 +101,8 @@ Microsoft Bob.
 By attempting to relate to users as people, these two products raised
 common-sense and theory-of-mind expectations that they proved incapable
 of meeting.
-Perhaps the set of software assistants that have recently started appearing
-on smartphones will fare better, but as of 2020 reviews are mixed.
+Perhaps the set of software assistants are now available on smartphones
+will fare better, but as of 2020 reviews are mixed.
 That said, the developers working on them by all accounts still develop
 the old way: The assistants might well benefit end users, but not so
 much their own developers.
@@ -112,17 +111,19 @@ This human love of fragmentary plans deserves more explanation,
 especially given that it is a classic two-edged sword.
 This love of fragmentary plans is apparently due to the assumption that
 the person carrying out the plan will have (1)~common sense and (2)~a good
-understanding of the intent behind the plan.
+understanding of the intent and requirements driving the plan.
 This latter assumption is especially likely to hold in the common case
 where the person doing the planning and the person carrying out the plan
 are one and the same:  In this case, the plan will be revised almost
-subconsciously as obstacles arise.
-Therefore, the love of fragmentary plans has served human beings well,
-in part because it is better to take random actions that have a high
-probability of locating food than to starve to death while attempting
-to plan the unplannable.
-However, the past usefulness of fragmentary plans in everyday life is
-no guarantee of their future usefulness in stored-program computers.
+subconsciously as obstacles arise, especially when that person has the
+a good understanding of the problem at hand.
+In fact, the love of fragmentary plans has served human beings well,
+in part because it is better to take random actions that have a some
+chance of locating food than to starve to death while attempting to plan
+the unplannable.
+However, the usefulness of fragmentary plans in everyday life is the
+everyday life of which we are all experts is no guarantee of their future
+usefulness in stored-program computers.
 
 Furthermore, the need to follow fragmentary plans has had important effects
 on the human psyche, due to the fact
@@ -142,15 +143,14 @@ normal, healthy life.
 Furtheremore, if you are not insanely optimistic, you are less likely
 to start a difficult but worthwhile project.\footnote{
 	There are some famous exceptions to this rule of thumb.
-	One set of exceptions is people who take on difficult or risky
-	projects in order to make at least a temporary escape
-	from their depression.
-	Another set is people who have nothing to lose: the project is
-	literally a matter of life or death.}
+	Some people take on difficult or risky projects in order to at
+	least a temporarily escape from their depression.
+	Others have nothing to lose: the project is literally a matter
+	of life or death.}
 
 \QuickQuiz{
-	When in computing is the willingness to follow a fragmentary
-	plan critically important?
+	When in computing is it necessary to follow a
+	fragmentary plan?
 }\QuickQuizAnswer{
 	There are any number of situations, but perhaps the most important
 	situation is when no one has ever created anything resembling
@@ -174,9 +174,9 @@ unwillingness of the decision-makers to invest enough to actually
 implement the project.
 A natural reaction is for the developers to produce an unrealistically
 optimistic estimate in order to be permitted to start the project.
-If the organization (be it open source or proprietary) is strong enough,
-it might survive the resulting schedule slips and budget overruns,
-so that the project might see the light of day.
+If the organization is strong enough and its decision-makers ineffective
+enough, the project might succeed despite the resulting schedule slips
+and budget overruns.
 However, if the organization is not strong enough and if the decision-makers
 fail to cancel the project as soon as it becomes clear that the estimates
 are garbage, then the project might well kill the organization.
@@ -186,7 +186,15 @@ A given project might well succeed only after killing several
 organizations.
 One can only hope that the organization that eventually makes a success
 of a serial-organization-killer project maintains a suitable
-level of humility, lest it be killed by its next project.
+level of humility, lest it be killed by its next such project.
+
+\QuickQuiz{
+	Who cares about the organization?
+	After all, it is the project that is important!
+}\QuickQuizAnswer{
+	Yes, projects are important, but if you like being paid for your
+	work, you need organizations as well as projects.
+}\QuickQuizEnd
 
 Important though insane levels of optimism might be, they are a key source
 of bugs (and perhaps failure of organizations).