What We Liked - in Parts 1 & 2
We suspect that the chapter titles listed in the previous section hardly do justice to the content. For example, in his introduction to Part 1: General Management, Joe observes that this first section of the book deals with generally useful stuff. And this Part starts with "Beginning at the Beginning" (Chapter 1). This is not so mundane as it sounds. Not just because many people prefer to start somewhere in the middle and work both ways, nor even start at the end and work backwards, but because it introduces the subject of software development and Joe's particular view of managing it. Chapter 1 also describes his "problem-solving clock" - an iterative creative cycle, as shown in Figure 1.
Figure 1: The iterative problem-solving clock
How do you know when you are done? According to Joe: "A good guideline is to stop when there is very little significant new information obtained during the observing and listening phases."
Chapter 2, Computational Roots, is an interesting foray into how computer science got started, how calculations were done pre and post the '60s and '70s. It will particularly delight older readers who remember the old slide rule with great fondness. For those who have never seen a slide rule, it is a hand-held device for adding logarithmic numbers thus enabling multiplication and division. It had the distinct merit that you had to have a feel for the answer before you started. Blind adherence to the number expressed to the n-th decimal place on the computer screen, regardless of whether such accuracy had any legitimacy, was still a thing of the future.
Chapter 3 uses mountaineering as an interesting analogy for planning a software project, while the chapters in Part 2 are all about the technical aspects of software coding. However, this is not as dry as it might sound, because Joe introduces us to his imaginary "old war buddy" of his Dad's named Roscoe Leroy. Joe says of him:
"Roscoe is one of those old salty dogs who have an opinion on just about everything."
"His wisdom is simple and easy to understand. It comes in the form of very prescriptive advice: As long as you don't probe for deep theory, you'll be fine. Going with Roscoe is a leap of faith, one that benefits us all when the chips are down. With his 'been there, done that' swagger, he boasts of having finished the eighth grade, but I have it on good authority that he graduated from an excellent high school some time in the thirties. My dad explained this discrepancy to me simply by saying that Roscoe felt it unnecessary to flaunt his education."
As an example, consider this exchange between Roscoe and Joe:
"Sometimes I hear software development project managers say 'We'll tackle that risk later; that'll give us much more time to think about it while we're doing all the easy stuff.' Whenever I hear that, my blood pressure goes through the roof!"
To which Joe replies:
"Ah, Roscoe, I know where that wrong thinking comes from. It's what we tell American students about how to take tests in a time-constrained setting. Over and over again, we admonish them to do the easy stuff first, to 'get money in the bank' and reserve the remaining time at the end to work on the harder stuff. The logic is to get as much credit as you can for what you know, and 'don't leave money on the table' because you run out of time ... [But in reality] the moral of the story is: Prioritize your risks, and attack the biggest ones first."
And Roscoe rejoins:
"Now you're striking oil, Sonny ... If I were behind schedule, I would feel much more comfortable going to my boss and asking for more time if I could demonstrate that my team was executing on a plan that had already squeezed out most of the risks. On the other hand, if I had to admit that not only were we behind schedule, but also that there were still high-risk items on the table, I'd be in a very weak negotiating position. I probably wouldn't get my extension, and the project might be cancelled. And maybe it should be."
3. Ibid, p1
4. Ibid, p7
5. Ibid, p9
6. Ibid, pp44-45
7. Ibid, pp52-53