It’s one of the few links that made it into the expensive real estate of my browser toolbar.

strangemaps.wordpress.com/

Here is one update I can talk about .. my hair makeover done by my beautiful wife. That is what I look like right now. Hal called it an "ugly baby" :-).

Enjoy summer!

bluxte.net/blog/2007-07/06-39-54.html

www.sun.com/emrkt/blackbox/index.jsp

www.datacenterknowledge.com/archives/2007/Jun/23/stanford_center_is_first_blackbox_recipient.html

www.youtube.com/watch?v=svLdboZdfQ0

nullstyle.com/2007/5/9/erlectricity-hi-ruby-i-m-erlang

www.brpreiss.com/books/opus8/

 I heard something similar just this week, actually.  It wasn't a
 manager--it was the person responsible for sales and support.  She
 said, in a discussion of the company's value stream, "Programming
 isn't the problem.  Once it gets to the programmers, we know it's
 going to get done."

 Pretty cool.  She was referring to an experienced XP team that's
 three or four years old.

 Cheers,
 Jim

 Hi,

 we're currently implementing some the XP concepts when we can see the
 reason for using a concept. Mostly this is due to some problems we
 identify. I'm not a consultant, but integrated into a development
 team, perhaps that allows me to see things from a different
 perspective.

 I found that people dislike "guessing" effort in time, because they
 feel bad if estimated ideal time is small compared to actual time.
 This can lead to the following problems:
 - overcommitment (but this time I'll do it in 2 days! really!)
 - undercommitment (if I guess a lot too much, I feel better if I'm wrong)
 - artificial pressure (I guessed 2 days, so I need to do it in 2 days,
 let's not do refactoring now)
 - demotivation (being wrong makes me feel bad)
 - problems with communication to product management ("but you said
 you'll do it in 2 days, now it took already 5!" - "but I said it's
 ideal time!" - "than tell us the actual time it will take the next
 time!" - "but I can't do that" etc)

 Using points solved this. Perhaps explaining to the developers that
 they have to accept that ideal time has nothing to do with actual time
 and that they should not worry too much about correctness of single
 guesses and explaining to product management that there are different
 time estimations (some in ideal time and some in actual time) would
 have solved the issue, too, but simply using points is clearer, since
 you make the distinction explicit if you communicate about effort.

 If I tell to product management that this item has size 3 and they ask
 me how long it'll take, then I tell them that if they include it in
 the current iteration they'll have it at the time the current
 iteration finishes.

 All this is less communication effort for me and thus increases ROI
 because I can work on code instead of nitpicking on the concept of
 time  :-)

 Cheers,
 Manuel

Skiing in Garmisch :-).