7/30/00 - Jack Harich - Go Home
Nice job, Ron, Ann and Chet. I'm a new strong supporter of XP. Haven't used it yet in production but am getting close. Am organizing a presentation on XP by experienced XP'ers for the Atlanta Java Users Group, and expect about 110 to attend.
I'd like to see XP succeed. Here's some feedback on your manuscript, as downloaded 7/29/00.
General Comments
The word "methodology" means "study of methods", not "a method", as common use is trying to redefine the word to. More accurate and professional is "process". A search shows it appears on page 151 and 152. A litmus test I use to determine "decency" is to search for misuse of words like this. Only two places. Not bad! :-) The page 151 usage is somewhat correct, but more clear is "software development processes have". The page 151 usage is incorrect. Better is "no existing design process".
My overall impression is it's a good, solid book with a very high signal to noise ratio. I'm glad to see "Functional Test" has been changed to "Acceptance Test", the term I prefer too. I'm also glad to see customers only design them now :-)
In general the book needs more visual aids. People learn better through visual organization of knowledge, or at least text heaviliy supplemented with drawings, diagrams and pictures. Remember, "A picture is worth a thousand words." My rule of thumb is to pass up books with nearly no visual aids. It means the author is not thinking somewhat like I do, and the book will be a hard and verbose read. BTW, figure 2.1 is very strong, a terrific way to start a chapter.
Table of Contents
I like the short overview per chapter. This allows quick scanning and overall book comprehension. This is a great format.
The many chapters could use grouping, beyond the "Bonus Tracks", which strikes me as arbitrary.. A scan feels chaotic. If the 23 first chapters "follow the chronology of a typical project", then show that as a group, not buried in the preface which not everybody reads, especially when they're getting an overview of the book.
Since the first chapter is an overview of XP, you might consider naming it "Overview of XP" or such. Naming it "Extreme Programming" says little, since the whole book is about XP. And if it is an overview, it should be left out of the "typical project" chapter group.
Getting a tad more detailed, the Chapter 1 summary phrase "Extreme Programming is a software discipline with values of simplicity, communication, feedback and courage" is a little hypish and vague. Better is the phrase I saw in the Application Trends article - "teamwork, testing, planning and simplicity". The XP'ers I talk to never mention courage, and only indirectly the other three words. Instead they speak of "teamwork" first and "testing" second, in popularity of words used. Courage is important, but I'd discuss it elsewhere. The problem is courage is too apt to turn off many developers and managers.
My summary of XP is "A new evolving lightweight software development process stressing teamwork, testing, planning and simplicity."
Forward
I assume the Forward will be the first thing in the book, rather than after Chapter 1. Nice to see the email I saw in comp-software.extreme-programming containing Dan's take on XP become the Forward. I feel he does hit the nail on the head, in a confrontational style supported by fact.
The sentence "First, what do I mean be Validation and Production?" contains a typo (be) and is confusing because the word "Production" hasn't been used yet. The confused reader must muddle along and translate from Product to Production and back many times. These words sound similar but have two very different meanings. I think you could clean it up and get Dan's approval, so that it doesn't deviate from his intentions.
Preface
Please don't be offended, but the italicized first paragraph smacks of hype. There's no reason to oversell XP, because the grassroots effort behind it is selling it, one mind share at a time. The paragraph makes XP sound like a Silver Bullet, and then you go and say, "There aren't any silver bullets in software development". The reader's mind has the rug pulled out from under it!!! I felt confused and doubtful. I'd tone the opener down. Also, try the phrase "software engineering" instead of "software development", which is what a process like XP brings to the table.
"In the introduction... you'll find an overview of XP and of the book. Hmmmmmm.... I missed this the first time. I'd not mix these - too confusing. Remember OO's maximum "Each class does one thing and does it well" applies to objects of any type. :-) As another example, how would you feel about a roadmap of the United States that also gave an overview of the history of the US? :-) Deep down, it's an unresolvable impedence mismatch.
"We became enthusiastic..." - Since I and many others view you, Ron, as the main author, the word "I" instead of "We" would be more appropriate here. But since you have 3 authors listed, try the paragraph opener, "The authors became enthusiastic...".
The first time "we" is used, identify who it is - Ron, Ann and Chet. I was confused, and thought it as a "royal we" belonging to Ron. Then I went to the website and looked at the book cover again, finding there were three authors.
Otherwise the Preface reads well and runs only one page. Nice job. But does it have good content? :-)
Keep in mind many reader skip the Preface. Me? About half the time. I skimmed the first two paragraphs of your Preface, and then skipped the rest because it lacked high content. Reading it again now, it says little of value to me. I wonder how this could be cured?
Chapter 1 - Extreme Programming
Ditto on the appearance of the phrase with "courage".
"key rights and responsibilities" raises a few hackles with me. Perhaps your author group is young, and still feeling newly empowered, and so feels rights are a big deal. Ten years from now you may look back on the use of "rights" with chagrin. However the use of the "rights" mentality is popular in the press at large, but nearly non-existent in the papers and books that are not so trendy. This is a subtle point.... Is XP some kind of emancipation proclamation? :-)
What to use instead of "rights"? Hmmmm.... I had to pull out my Thesaurus on this one to jog my brain for ideas. Going ahead in the chapter to page 16 where "Rights / Responsibilities" appears, I believe what you're presenting is the "key benefits" that managers and customers can expect.
In fact, I just noticed the word "benefits" in your italicized paragraph! I disagree that it's useful to "express these as rights because they are very important to the success of the project". For example, the configurable process I use has a step where one collects "Key High Value Goals" for the project from the customer, such as "Easy to learn", "Productive immediately" and "Flexibility". These are essential to the customer for the project to succeed. Should they become "rights"? Of course not. That would confuse and turn off the customer.
Here's a reworked section so you can see the result of switching to "benefits":
Key Benefits
Extreme Programming tries to provide certain key benefits to the managers, customers and developers in a project. These benefits are absolutely crucial to success of the project, so much of XP's practices provide and enhance the key benefits..
|
Manager and Customer Benefits |
| 1. An overall plan showing what can be accomplished, when it can be done, and at what cost. |
| 2. Getting the most possible value out of every programming week. |
| 3. Seeing progress in a running system, proven to work by passing repeatable tests that you specify. |
| 4. The freedom to change your mind, to substitute functionality and to change priorities without paying exorbitant costs. |
| 5. Being informed of schedule changes, in time to choose how to reduce scope to restore the original date. The project can be canceled at any time, leaving a useful working system reflecting investments to date. |
|
Programmer Benefits |
| 1. Knowing what is needed at all times, with clear priority. |
| 2. The freedom to produce quality work at all times. |
| 3. The freedom to ask for and receive help from peers, superiors and customers. |
| 4. Ease of making and updating your own estimates. |
| 5. Choosing your responsibilities instead of having them assigned to you. |
BTW, you have some golden nuggets here in your benefits. Congrats!!!
The paragraph beginning with "The first book in the..." should be moved to the Introduction. This chapter is an Overview of XP, not the book.
"...using teams of a dozen or fewer programmers in one location." - Will XP work with one developers? Have you changed from the "teams of 2 to 10 programmers" stated in Extreme Programming Explained? If so, then this large change needs to be explained. :-) Be sure to include what happens to Pair Programming in a one programmer project.
The section beginning with "Customers - those who..." describes what the book offers, not what XP offers. I'm cornfused (sic). The chapter seems to be a mixture of an overview of XP and the book. In any event, the section needs delineation, such as a header like "What Customers, Programmers and Managers Will Learn".
Then another header is needed - "The Roles of Customers, Programmers and Managers". This section seems to be an overview of XP and deserves being in this chapter.
Very good content in this section. You might consider a chapter on roles.
The section on "Rights / Responsibilities" was discussed above, since the topic was introduced in the first chapter paragraph.
I assume the editor will help you better layout the rights and explanations. Hey, this is a manuscript! :-) There's some great content here. If your rights (benefits :-) are numbered as the above example, use the same numbers in this section.
"Project Flow - The rest of the book..." - Again, you are mixing content about the book with content about XP. Perhaps move the first two sentences in the "The rest of the book.." paragraph to the Introduction. The rest needs reorganization into a crisp overview of XP Project Flow. Try a diagram or table.
The last paragraph, beginning with "Finally, we include some Bonus Tracks...", fits better in the Introduction. As laid out now, it's part of Project Flow! :-)
Is the above helpful? Facing a soonish publishing date, is there time for me to review more and you to use it? If so I'll be glad to continue.
BTW, I have my own (additional to Dan's) suppositions about why XP works so well:
- Mainly the many "multiple stage multiplier effects" of the 12 Main Practices. This gives an Gestalt effect because the whole is far greater than the some of the parts. I'd be glad to diagram this out, and have already done a small portion for my own understanding and presentation to a study group I lead.
- The ability to appeal to and be used by the lowest common denominator developer, whose mature skills are limited to coding and talking. Practices like heavy OO modeling, reuse, inspections and architecture can be added by those competent in them, which is few. So XP is "skill scalable" and still super easy to use.
- It's so different from mainstream processes it appeals to the younger generation, who always wants to rebel. The very name, Extreme Programming, says "I'm different". Of course, I feel that this is A Good Thing because what XP offers is needed.
- One could say XP is an ice cold bucket of fresh water in the face of the popular heavyweight processes that cause more problems than they solve. XP fills a backlash vacuun.
Keep up the rather good work,
Jack Harich
1164 DeLeon Court
Clarkston, GA 30021
404-296-5284 home/work
mailto:jack@jcon.org