Red Squirrel Reflections
Dave Hoover explores the psychology of software development

Dave Hoover
dave.hoover@gmail.com

Categories
All [Atom]
Craftsmanship [Atom]
Dynamic [Atom]
Intersection [Atom]
Learning [Atom]
Links [Atom]
Polyglot [Atom]
Projects [Atom]
XP [Atom]
Old Blog

Obtivian Blogs

Andy Maleh
Colin Harris
Fred Polgardy
Jim Breen
Kevin Taylor
Todd Webb
Turner King
Tyler Jennings

Archives

March 2009 (1)
January 2009 (1)
December 2008 (1)
October 2008 (3)
September 2008 (1)
June 2008 (4)
April 2008 (3)
March 2008 (1)
February 2008 (1)
August 2007 (1)
July 2007 (1)
June 2007 (1)
May 2007 (4)
April 2007 (3)
March 2007 (5)
February 2007 (6)
January 2007 (6)
December 2006 (10)
November 2006 (5)
October 2006 (8)
September 2006 (8)
August 2006 (5)
July 2006 (12)
June 2006 (7)
May 2006 (5)
April 2006 (5)
March 2006 (4)
February 2006 (2)
January 2006 (5)
December 2005 (5)
November 2005 (3)
October 2005 (3)
September 2005 (6)
August 2005 (4)
July 2005 (7)
June 2005 (14)
May 2005 (6)
April 2005 (8)
March 2005 (9)
February 2005 (11)
January 2005 (16)
Old Archives

 

Mon, 28 Mar 2005

Reconsidering "Sustainable Pace"

It just occurred to me that I might have a problem with the term "sustainable pace" used in the context of extreme programming. Or perhaps I've never fully understood this idea and someone needs to enlighten me. I was just doing a bit of writing and was using "sustainable pace" in a sentence when it occurred to me that when I use the term "sustainable pace," I'm focusing on working a reasonable number of hours per week.

But "pace" doesn't refer to a quantity of time, it refers to a rate of speed.

I find myself wondering whether this phrase might be sending the wrong message. By metaphorically linking the number of hours worked with the speed of the team, are we implicitly discounting the idea that the speed of the team might be relatively independent of the number of hours worked?

[/xp] permanent link

An Argument for Pair Programming

Johanna was asking for some help with explaining pair programming to some skeptical managers. My off-the-cuff response:
Some managers like pair programming because when the software is released, managers can go to almost any developer with almost any problem and the developer will be able to handle it. Pair programming destroys knowledge silos.

[/links] permanent link


powered by blosxom