>An activity that I /do/ still have trouble with, however, is writing.
 > When faced with having to compse anything more substantial than an
 > email response, I feel the fear start to creep in and I get myself all
 > tied in knots.  Even after I start to put some words down, I often
 > find myself getting stuck because the thing isn't flowing and the task
 > of finishing seems overwhelming.

Yup, writers block definitively, as John Roth diagnosed already. But if you’re able to describe it in such flowering detail as above, there’s no need to have it.

 > So on my way home last night (after another frustrating couple of
 > hours trying to get some thoughts on paper), I was thinking about how
 > I could make my prose writing come as easily as my code writing.  I
 > started wondering if I couldn't somehow employ a TDD-like cycle in my
 > writing process.

I am often writing articles with my business partner, who’s<br>especially good at collecting lots of nice stuff on the web. The first thing I have do with the "drafts" I get from him, is to find the<br>structure fitting best to the available data. This is currently donein a Mindmap using freemind (freely available at sf.net, IIRC). For some<br>time I also tried vimoutliner (www.vimoutliner.org) for this, but found that for this process, the two-dimensional display of a mindmap is better suited to my brain.

When the outline is finished, I start to grow the flesh on the bones. That’s relatively easy, as I confine my work strictly to the current paragraph.>

The next step is easy, if I have the time: I let the stuff settle for a few days, then go over it once more and clean up the unbelievable mess I created then. If I don’t have the time, I need to play about two hours nethack, which erases my brain just as well…

So the steps are:

 - data collection
  - gradually by experience
  - by force (coauthor delivery)
 - data organization
   - mindmap
   - outline
 - draft
   - follow the map
   - work local
 - refactor or polish
   - grammar, spelling, rhetoric
   - present line of thought more clearly

I think that there’s a difference between code and prose showing here. You expect your code to give certain results for a given input, and you are free to not care about the implementation at all. With prose, implementation is almost everything. So the cost of providing a "working release" is higher with prose than with code. At least for me.

 >find myself getting stuck because the thing isn't flowing and the task
 >of finishing seems overwhelming.

Writing is like every other kind of art. It is never finished. Feeling better now?

Writing is like dealing with animals. Don’t be afraid of it, and it won’t hurt you.

Your fellow author in pain, S.

(Source: Ron Jeffries in the XP-mailinglist) Well, Don't do Code Reviews, do Pair Programming. Frankly, code reviews are /so/ much worse than pair programming that a dose of them would make me fly to pair. Let's see if we can replicate my experience.

Here's one path through a network of a million decision points:

To do code reviews, everyone has to read the code beforehand, unless you're doing a walkthrough, see below. I'd ask everyone to come together physically to the review. Then I'd ask them to report truthfully how much time they spent reviewing the code. Early on, I would report truthfully that I had spent zero or very little time, in hopes of getting others to admit the truth. When they admit the truth, I'd dismiss the meeting and reschedule it.

Then, after a while, the only alternative is a walkthrough, since no one is preparing effectively for the review. So we do walkthroughs for a while. They are intensely boring, and few people stay involved. Note in your mind the people who are present but not involved. At the end of the session, say, holding your hand up, "Who else had a real problem staying engaged with this walkthrough?" If there's honesty in the room, hands will go up. Prompting may be necessary. Then: "Any ideas?"

Surely someone will think of "doing this in smaller groups or one on one". Try it. Ask the team whether "we should empower the one-on-one folks to change the code, and under what circumstances." Don't mention that this is pair programming.

Try an experiment. You're "interested in collaborative programming". Interested parties should come to the room to help. On the screen, start writing a program. Ask for help with it, get the room to pair with you. Get stuck (no need to fake this if you are me). Someone will start telling you what to do. Don't get it (no need to fake this either). Get them to come up and do it ... grabbing the chair that is accidentally beside you, while you move over.

Note that reviews often find things. Observe how many of them are resisted by the original programmer, or are "too much trouble to fix now". Build a few BVCs relating to time spent prepping, in the meetings, number of useful suggestions (by person if you can do it without problems), number of changes made in response to suggestions, ...

Code reviews are intensely painful, in my experience, and we were trained by Freedman himself. There will be no need to set them up to be perceived that way, though it will take honesty among the group to express it. After doing enough code reviews, which take way more than half the groups' time by the way, a team who has heard of pair programming should be begging to pair. About all you have to do is make sure that no one treats the review session as nap time, and that you are /early/ in recognizing the people who think it's a waste of time. Because they're right.

 A quote from "Pirates of the Caribbean: The Curse of the Black Pearl":
 --You're pirates. Hang the code, and hang the rules. They're more like
 guidelines anyway.

Amongst other things this article tells you when best to have children :-). [groups.yahoo.com/group/extremeprogramming/files/when%20should%20we%20test.pdf]

In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. He invented the worlds first wiki, a web-based collaborative writing tool, to facilitate the discovery and documentation of software patterns. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming. link

I think that to get a group to be agile, you have to get people to do something like one of these things:

1. Go in that room there and do all 12 XP practices until you actually do know better. (XP)
2. Go in that room there, don’t let anyone screw with you, work on whatever you think you can get done for a month. Keep doing that until everyone is happy. (Scrum)
3. Go in that room there, in peace love and understanding, ship software every month (*), and think about it. (Crystal Clear.)

There is a telling sameness to all of these, is there not? —> This is a wonderful summary of a summary! There’s not much to be removed (see Saint-Exupery, below). In Italian, the expresso of an espresso is called a "ristretto" (any Italians online?). This is the agile ristretto. It belongs on a Blog or something. "La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever." (Saint-Exupery)

How can software development productivity be increased? Through the same approaches used in operations: a focus on customer value, a short, effective supply chain, healthy discipline, and innovation. Mary will discuss techniques that businesses have used for decades to jump-start an increase productivity, and show how they can be used to increase software development productivity. pdf

But there are similarities: software is developed in stages, it is created in a process amenable to change, and it’s developed in a team. Lean manufacturing is a different approach than a traditional assembly line, and offers some lessons for software development. xp123.com/xplor/xp0312/index.shtml

"Process waste" is the behaviors that don’t produce a working product. The biggest waste in the industry today is "programming in the debugger". This is so endemic nobody even calls it waste. Our vendors work very hard to supply us with advanced debuggers, so we can merrily cause problems and then fix them, instead of preventing problems.

Another big waste is delayed integration. Some shops account for how many modules we must write, then specify the modules’ interfaces, and tell each programmer to write a module separate from the others. Then at the end of this cycle the programmers start trying to integrate. They might not even have build scripts to plug the modules together; they might find themselves manually integrating by clicking on the user interface to an IDE.

Delayed integration costs some orders of magnitude more than the cumulative cost of continuous integration does.

Get ahead of these problems. Write tests first, constantly review code, don’t own code, and integrate continuously. Write and maintain build scripts that support all these behaviors seamlessly.

Don’t delay surprises. If "our product has an installer" appears as a motherhood story, integrate the installation system early, and test it every day. Don’t wait for the last iteration.

The ideal is that the last week before a big release should look and feel just like any other.

Phlip:

 During the planning game, you review last week's
 finished stories, and they inspire you to write some
 new cards, to edit some cards, and to toss some cards.
 Then you (the Onsite Customer) re-sort all the cards,
 and draw off the top batch for the next week.

 But another input into this system that affects the
 planning game - the competition.

 The USA occupied Iraq using an effective new battle
 technique. In traditional advances, you send a
 diversionary force against one of your enemies flanks,
 draw them that way, then send your main force against
 their other flank.

 Modern soldiers, with cell-phones and such, follow a
 more agile approach. You simply send two forks of your
 forces, probing towards both flanks. You use sensitive
 algorithms to detect the defending commander's
 decision which flank to defend. If you can rapidly
 turn one advance into the diversion, and the other
 into the main attack, you will soon collapse the
 opposition's ability to effectively make decisions.

 Agile onsite customers can play this card too. If you
 detect your competition's marching orders, in
 real-time (using either sensitive algorithms,
 good-old-fashioned industrial espionage, or just
 reading their self-congratulatory Web site), you can
 then request iteration features which provide the
 minimum amount of code needed to start your project
 towards blocking the competition's advance. This
 technique will, again, collapse the competition's
 ability to make decisions.

 Or convince them to hire an XP coach or three. So
 either way it's a win-win-win for us! ;-)

Steven’s reply: :-)

 Or you could follow the agile strategy that Microsoft
 pioneered - announcing products with your competitions'
 features before you even start implementing them.

Basically it’s an ad for Whiteboard Photo. ;-)

 >Reciprocity is not guaranteed on airlines (or toll bridges - it
 >has always amused me that the toll on the Severn Bridge between
 >England and Wales is GBP 4.20 for a car to enter Wales but there
 >is no toll the other way, ie entering England). (Maybe it shows
 >how the two countries value themselves?)

All of the bridges in the San Francisco Bay area only charge toll in one direction. Some genius realized that, on the average, just about as many cars went each way for the obvious reason that most trips across the bridges are round trips. So they doubled the toll and took down the toll booths going one way (except for the Golden Gate Bridge where the toll booths remain, unattended). There has been considerable saving in toll collection costs and the toll booth traffic jams in one direction are gone. Is it possible the Severn Bridge does similarly?

• Eliminate waste: Spend time only on what adds real customer value
• Amplify learning: When you have tough problems, increase feedback
• Decide as late as possible: Keep your options open as long as practical, but no longer
• Deliver as fast as possible: Deliver value to customers as soon as they ask for it
• Empower the team: Let the people who add value use their full potential.
• Build integrity in: Don’t try to tack on integrity after the fact - build it in
• See the whole: Beware of the temptation to optimize parts at the expense of the whole

Link

Amongst other things this article tells you when best to have children :-). groups.yahoo.com/group/extremeprogramming/files/when%20should%20we%20test.pdf

I’ve been thinking about the problems of applying XP to whole organizations. Turns out this is ground thoroughly covered by the lean production folks.

Here is a paper I found helpful: www.nwlean.net/no_harm.zip The premise is that every step of the transformation must pay for itself.

Getting people to understand that their problems are tractable can be hard, I’ve found. Rob Mee was talking to a guy about TDD on a gig of ours recently. "Sure, yeah, TDD is a great idea." "Why don’t you do it?" "It’ll make us go slower." "But it makes you go faster." "Yes, of course, but it’ll make us go slower." "But it’ll make you go faster" *iterate N times for annoying large N* "Okay, it makes people go faster everywhere but here."

As part of my interview, I was required to sit and pair program for about half an hour. We worked on an writing a unit test for an actual defect that currently existed on the project (although it could easily have been a real user story, or a contrived scenario if the project had not yet started).

I thought this was a great idea, and a great source of knowledge for both sides. I was able to show that I did indeed know how to program, write unit tests, knew my way around an IDE, had acceptable interpersonal communication skills, etc. I was also able to get a different perspective on what the team dynamics were like, which I could not have gotten from a formal interview setting.

The interesting thing is that both me and my partner (one of the interviewers) taught each other about some tools and approaches that we were not previously aware of.

Even though I didn’t get the job (the position was withdrawn), I kept in touch and became friends with the interviewer/partner, and the things we taught each other came in useful in our future development work.

This company also asked for code samples and a mini-presentation, which I also thought was a great idea for separating the wheat from the chaff.

Since I have had responsibility for helping interview, select and recommend job candidates in the past, I know for a fact that the best resume and interview performance in the world is inconclusive. You can still get a lemon, even though the lemon may be very good at piling on the BS.

From my perspective as a job candidate, I am confident in my skills and my abilities. I know that I can quickly adapt and excel in any position within my skill set. However, its very frustrating when I cannot convince the potential employer of this through only a traditional resume and interview.

In future interviews that I go for (which will hopefully only be with XP/Agile shops), I am going to suggest this as a way for the hiring company to get a better idea of my skills, knowledge and abilities, both technical and interpersonal. If I am ever part of a hiring team in the future, I will definitely propose that code samples and a pair-programming session be part of the interview process for candidates who make it to the final stages. This is admittedly very time-consuming, but probably much less net investment than being forced to live with (or try to get rid of) an employee who looked much better "on paper".

Thanks, Chad