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

Sun, 27 Mar 2005

From Apprentice to Journeyman

I am forever chomping at the bit to create something novel. From a very young age, I have wanted to write a book. And I still do. My ideas for what to write about have changed radically over the years. From fantasy to science fiction to children's poetry to adolescent psychology to programmer psychology and now onto software craftsmanship.

Pete wrote about the new imperative of software craftsmanship. Dave and Andy wrote about the practices that can take you from journeyman to master. But how does one transition from apprentice to journeyman? This is the journey that I have been on over the last several years. And some thoughts are spinning around in my head about how to communicate to aspiring software craftsmen what has worked for me.

But I've got a bit of writer's block lately. I am trying to keep the words of C.S. Lewis in the back of my mind:

"No man who values originality will ever be original. But try to tell the truth as you see it, try to do any bit of work as well as it can be done for the work's sake, and what men call originality will come unsought." --The Weight of Glory, p. 175

[/craftsmanship] permanent link

Sun, 20 Mar 2005

The Motivation of the Apprentice

"People master a craft because they care enough about the craft to make the effort." --Software Craftsmanship, Pete McBreen
I have been pondering Pete's quote for the last few days, questioning why I want to master the craft of software development. I have realized that my desire to master this craft is not due to my caring about the craft itself. My desire is the result of the joy that I experience when I have created something with software. I admit it's a self-gratifying desire. I'm not driven to improve as a craftsman in order to please my customers, to make more money, to impress my employer, or to become a luminary in the industry. I'm doing it because I love the act of creating something from nothing, of creating order where there was disorder, from growing something elegant out of something simple. I like the way Fred Brooks said it...
"Why is programming fun? What delights may its practitioner expect as his reward? First is the the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake." --The Mythical Man Month, p. 7
If you are someone who aspires to become a master crafsman what is your motivation?

[/craftsmanship] permanent link

Wed, 09 Mar 2005

A Computer for my Kids

I bought my kids a mini. In order to prolong the life of this beautiful little machine, I decided that everything that my kids would touch on a regular basis should:
  1. Cost less than $50: less painful when (not if) they break stuff
  2. Be physically detached from the computer: less likely to break more than one thing at a time (think of dominos)
So I grabbed a bluetooth apple keyboard and a bluetooth kensington travel mouse from Ebay. I also grabbed an inexpensive (and lightweight) LCD monitor from Amazon. I am very happy with this little system. Once I had all the accessories in place, I turned it on, the mouse and keyboard were detected immediately, it picked up my wifi network, and off they went.

[] permanent link

Tue, 08 Mar 2005

Quote Manager Source

Posted the source at http://redsquirrel.com/dave/work/QuoteManager/QuoteManager.zip

[/projects/quotes] permanent link

Fri, 04 Mar 2005

Apprenticeship Program in Jeopardy

Rachel is waving a red flag, hoping that the agile community will take notice:
"I am writing this blog to express my personal support for the Software Development Apprenticeship (SDA) program at New Mexico Highlands University. The program's unique approach to remunerated experiential education prepares student apprentices for careers as agile developers who understand the value of people and craft in the development of humane software systems."
Linda's description of this program encourages me to keep my own dream alive of starting a local apprenticeship program someday:
"The Bachelor of Software Development Apprenticeship (SDA) program at NMHU is the realization of Dave [West]'s long-held goal: teaching students in a community to use software development as a lever to change the world instead of using it as a tool for doing the same things people have always done more quickly and accurately. This reflects his belief that the key to improvement is better people rather than more rigidly specified processes."
According to Rachel this program is in danger of being cancelled. It's not clear how people can help out, but it sounds like Rachel will have more info soon.

[/links] permanent link

Tue, 01 Mar 2005

Be the Worst

When asked to give advice for young musicians, Pat Metheny said...
"I have one kind of stock response that I use, which I feel is really good. And it's 'always be the worst guy in every band you're in.' If you're the best guy there, you need to be in a different band. And I think that works for almost everything that's out there as well.
This sums up perfectly why I came to ThoughtWorks. It also feels like it could be a seed for an apprenticeship pattern language. More on this in the weeks ahead...

(Via Chris Morris.)

[/links] permanent link

Crisis Acceleration

In their excellent Organizational Patterns of Agile Software Development, Jim Coplien and Neil Harrison pointed out...
"...changes at this [the organizational] level do not come easily. It may take years, or perhaps even a crisis, to shake the foundation of the organization--it's value system." page 311
Whenever I hear "crisis" and "change" in the same breath, I think back to a child and family therapy technique called raising the bottom. And I ponder anew how this concept could be applied appropriately to software development.

Agents of change are well aware of how difficult it can be to affect change in others. But they also know that the fastest route to significant change is a crisis. They have a challenging problem with a tricky solution.

The good news is, we have the solution. The bad news is that humans tend to dislike this solution (a crisis) even more than change itself. Even worse, no one wants to be the cause of a crisis, because those people tend to be targets of blame. But what if we could openly and responsibily accelerate an organization or a team into a crisis in order to bring about change and avoid a more dangerous crisis down the road?

The classic example of a crisis acceleration: Parents who cut off their drug-addicted child, leaving him to fend for himself. The parents would have already engaged the system around the child to help him have a controlled landing. They coordinate with the police, the school, therapists, friends, relatives, as much of their child's system as possible. What sort of parents would do this? Parents who are convinced that their child is going to end up dead in a gutter. They would rather have their child hit rock bottom on their terms.

Food for thought...

"It may look like a crisis, but it's only the end of an illusion." --The Secrets of Consulting

[/intersection] permanent link


powered by blosxom