On Models

Brian Marick has written a tantilizing post The Stance of Reaction. In it he says

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me. (Continued)

Accounting for Spikes

The term Spike Solution is associated in my mind with the early days of Extreme Programming.  I’m sure that it is built from prior ideas, as everything seems to be. If the term and the concept it describes predates the Chrysler C3 project (Ron Jeffries mentions using it there), I’ve not yet uncovered it. Ron credits Ward Cunningham for the term.  I’m sure there are predecessors, even if not expressed as distinctly.

The goal of a spike solution is to answer a question. For example, a spike may be used to test the feasibility of an algorithm or 3rd party library. It may be used to explore design alternatives for solving a sticky problem.  It’s called a spike because it drives all the way through the problem, but as narrowly focused as possible. It’s not a complete implementation. Associated complexity that is secondary to the question is likely stubbed out to reduce the clutter and increase the focus. (Continued)

Building sand castles on a rising tide

Grabbing a handful of wet, saturated sand, I let it dribble through my finger tips.  I watch each drop pile on top of the previous, draining away the water and leaving a new building block of solid sand.  Too much water and the previous drip will be washed away.  Too little and the sand cracks and refuses to hold together.  I watch the sand grow, getting into a rhythm that ensures just the right amount of water, without thought.

My thoughts are not on the mechanics of building a drip castle with sand.  Instead, I’m thinking of the spire that I’m building.  Can I build these two spires toward each other and form an arch?  Can I make this slender spire taller?

Frequently I fail and a part of the castle slides down, becoming part of the landscape again.  Or becoming a foundation for a new part of the castle.  No matter.  It’s the building of the castle that brings me joy–not the owning of it.  For I will never own it.  The sea soon comes and takes it away.

Last weekend, I drove six hours down to Floyd, Virginia for a Code Retreat organized by Gustin Prudner and led by Corey Haines.  There, I joined thirty-some people working in pairs and threes on Conway’s Game of Life for forty-five minutes at a time.  Then, Corey would call time, and we would wash away all traces of what we’d built.

Does that sound like a waste of time?

(Continued)

Of course it’s a misnomer

On Twitter, my good friend Mike Sutton said, “CSD is a misnomer. The value of existing Certifications needs to be justified before new ones are released.”

Many of the terms we use are misnomers.  For example, “acceptance testing” is a misnomer because it doesn’t indicate acceptance if the tests pasts–it indicates lack of acceptance if the tests fail.

What is the misnomer in the phrase “certified scrum developer?”  (Continued)

Agile Retroflection of the Day

Yves Hanoulle asks, “If you could change 1 thing today what would it be?” as the first question in his Agile Retroflection of the Day project. Today being the first of the year, it’s natural that I look back over the past year as I consider this question.  And so I answer,

That people could ask for, and could accept, the help they need and want. (Continued)

Proficiency and Fluency in Self-Organization

Ever since I experienced the “Where Are Your Keys” language fluency game with Willem Larsen, I’ve been thinking about how to apply the concepts to learning other than languages.  One of the fascinating concepts I gleaned from this game is the separate dimensions of proficiency and fluency.  The proficiency scale that Willem uses is based on the ACTFL guidelines of Novice, Intermediate, Advanced, & Superior.  Willem gave a memorable colloquial description of these guidelines in relation to a party: (Continued)

What would you like your software developers to learn?

I posted this question on LinkedIn this morning, and have already received a ton of answers. I thought it would be good to ask here, too.

As a manager, what would you like the software developers under your management to learn? This might be knowledge of some specific technology, some software engineering skill, some other skill or knowledge, or what?

Your answer doesn’t have to apply to all of your developers. Pick something that will make a noticeable difference in your organization’s effectiveness. And please be as specific as possible.

Of course, some of the answers were general advice rather than specific things at the answerer’s organization. But where the answers were specific, I typically followed up with two more questions.

What steps are you currently taking to help developers learn this?

What steps do you think you should take, but aren’t yet, for some reason?

I’d like to hear your answers, either as comments to this blog or privately in email.

Learning from experience

It is good when we learn from our experiences–much better than when we don’t learn from them. I recently wrote about learning, or failing to learn, from observing others. A recent discussion on the scrumdevelopment yahoogroup got me thinking about another way to learn from experiences, and that’s learning from the experiences of others.

The discussion I mean started in the middle of another thread, when Clay Dreslough asked about Pair Programming.

But I have never had any success with actual Pair Programming.

So … am I missing a key component of XP? Or have other people found the same reticence with adopting Pair Programming?

Are there some valuable gains here that I’m missing? And if so, how would you recommend getting programmers to change their habits? (Continued)

What do you know?

A while back, I was working with a young and cocky software developer. He was a smart guy, and sure of his abilities. He had seven years of Java experience, he said, and he knew how to write code.

As he was a new member of the team, I described the strategy I’d planned for a bit of code. I showed him what I’d already written, and asked him to complete the functionality.

“But I can do it another way.” And he described a different technique. (Continued)

Learn the trade and the tricks will follow

I’ll never forget the 11th grade English class when Mr. Ervin departed from his usual lessons in literature, and lectured us on this topic for the full hour. “Learn the trade and the tricks will follow.” As he repeated this simple advice, he bemoaned the fact that everyone was looking for the shortcuts, looking for the quick and easy, trying to bypass learning any more than was necessary.

Where did he learn this advice? As a carpenter’s apprentice, he had noticed that the master carpenter always had some little trick or technique to apply in difficult situations to make them easier. Carpentry was hard work, and he though if he could learn all of these techniques, it would be much easier to learn. So he asked the master carpenter to teach him the tricks of the trade. “Learn the trade and the tricks will follow,” was the reply. (Continued)