Red Squirrel Reflections Dave Hoover explores the psychology of software development

"The greatest risk we face in software development is that of overestimating our own knowledge." --Jim Highsmith, Adaptive Software Development, p. 14

Back in my former life as a family therapist, I strove to apply the principles of narrative therapy with my clients. Ever since my first exposure to agile software development I felt it shared underlying philosophies with my chosen theory of family therapy. Every time I find evidence of this, I get all excited...

One of the foundations of a narrative (or collaborative) approach to therapy is the adoption of a not-knowing stance. Taking on this stance evokes an attitude of genuine curiosity and breaks down the hierarchical barriers that naturally exist between client and therapist. For more on this stance, read this, this, or this.

Here is a teaser from that last one:

"Assuming this not-knowing stance, collaborative practitioners invite multiple, contradictory voices into therapeutic conversations, which allows participants to generate and explore new perspectives and meanings together."

I've been quoting The Fifth Discipline like crazy over the last month. Although I've finished the book, I guess old habits are hard to break. Here is a quote that relates to the not-knowing stance:

"The facilitator always walks a careful line between being knowledgeable and helpful in the process at hand, and yet not taking on the 'expert' or 'doctor' mantle that would shift attention away from the members of the team, and their own ideas and responsibility. (246)

This applies directly to the work of the therapist and the consultant. We strive to be helpful without creating a dependency. We are conscious to encourage the client to be responsible for the problem we are helping them with. Taking on the mantle of an expert encourages dependency, while a not-knowing stance will lead to collaboration.

I finally started reading Adaptive Software Development by Jim Highsmith. When I read the following quote, it rang true with my experiences as a software developer. Just as in a therapeutic relationship, a not-knowing stance facilitates learning and collaboration within a software development team:

"At the core of our ability to succeed in extreme environments is the admission that we don't know it all, that we need to enrich our understanding through better attention to how we explore our world, to how we collaborate, to how we learn--in essence, to how we adapt as living systems." (14)

I actually had a foreshadowing of this idea back in 2002.

I think the not-knowing stance also ties into Steve McConnell's advice to assume it is your fault.

Posted by Dave [Link]

As I reached chapter 16 of The Fifth Discipline I did a double take when I saw the title of the chapter: "Ending the War between Work and Family." This "war" has impacted my life significantly since I started travelling 2-4 days/week, two months ago. It has been an incredible struggle to maintain the balance that allows me to be a successful husband and father, while simultaneously excelling in a technically strenuous workplace. I can count on one hand the number of days in which I have actually felt I acheived this balance.

The chapter was just what I needed to read. It talked about the blurring of the line between personal and professional life and the need for people to explicitly strive to integrate the two: "We live only one life, but for a long time our organizations have operated as if this simple fact could be ignored, as if we had two separate lives." (307)

This reminded me of RoleModel Software's vision statement.

One of the aspects of software development that I find to be very gratifying is the opportunity to solve some difficult, yet objectively "solvable" problems. This was a novel experience for me when I left the world of family therapy, where the problems were always much harder to pin down and "solve." I feel like I need to explicitly reframe this balancing act as a problem to solve, to strive to discover new and interesting ways to be successful as a husband, father, and consultant.

I'll sign off with my favorite quote from chapter 16. Bill O'Brien says:

"The more I understand the real skills of leadership in a learning organization, the more I become convinced that these are the skills of effective parenting."

Posted by Dave [Link]

My appetite for learning drives me to read as often as possible. This appetite was sparked when I started learning my first programming language in late 2000. By late 2001, I was a full-blown bookworm. Soon after, I started scribbling and underlining continuously as I read. This eventually evolved into transcribing my favorite quotes onto a piece of scratch paper that I kept as a bookmark. Having all of those interesting thoughts on scratch paper seemed like a waste, so I started transcribing them onto a web page. Over the last couple years, that simple page of HTML has steadily grown, and is now close to 200K.

My wife and I are on the plane to Ft. Lauderdale right now (a quick weekend getaway for our seventh anniversary) and I was reading The Fifth Discipline (surprise, surprise). With two pieces of scratch paper completely full of quotes, I figured now would be a good time to take a break from reading and start transcribing onto my quotes page. When I got to the following quote, I noticed that I had written some thoughts after it.

The quote:

"Even if we feel uncertain or ignorant, we learn to protect ourselves from the pain of appearing uncertain or ignorant. That very process blocks out any new understandings which might threaten us. The consequence is...teams full of people who are incredibly proficient at keeping themselves from learning." (55)

My response:

"That is the dissonance I feel...the pressure to appear competent when I feel out of my league...when I have been trained to come at things from a "not knowing" perspective...to be transparent about my ignorance in order to facilitate learning."

The context of my response was based on my recent experiences on a new project in which I was brought in to replace a colleague who was significantly more experienced and technically gifted than myself. Being transparent about my assessment of myself with my client has been valuable in developing an open relationship and with accelerating my learning of this unfamiliar domain.

Posted by Dave [Link]

A colleague of mine is under a heavy pressure to repair and reimplement a piece of functionality by a specific date. The criticality of the functionality and imminent deadline has led him to abandon writing tests first.

This scenario took me back to my previous job where we tried and failed to adopt the discipline of writing our tests first. My recent exposure to The Fifth Discipline helped me view these related situations as systems, specifically the "shifting the burden" system archetype...

An example of "shifting the burden" that we have all likely seen is the emergence of addictive behavior. It all begins with some sort of problematic symptom (stress, depression, illness). A given problematic symptom will have one or more fundamental solutions (lessen workload, seek treatment). But all too often, the easier and more immediate "solution" is to suppress the symptom (alcohol, unhealthy relationships, pain killers). With the symptom suppressed, the problem is left untreated. Over time, the symptomatic "solution" will become less effective (the body develops a tolerance, relationships crumble) and an ever-increasing dependence on this false "solution" will develop, requiring more and more of the "solution" to keep the problematic symptom suppressed.

To bring this back into the realm of software development, the problematic symptom is time pressure. The fundamental solutions that could treat this symptom include delaying the release or shipping without the functionality (there are probably other solutions that I'm not thinking of). One of the easiest and most immediate ways to suppress the symptom of time pressure is to stop writing unit tests.

"Ahh, now we're moving much more quickly! See how much code I can crank out when I don't have to take such small steps? Look how fast I'm going!"

With a fair amount luck, the deadline will be met and the software will be released with the desired functionality in place. But the damage has been done: the software has untested code and a dependency has emerged. When the time pressure reappears (which is now more likely with untested code), the abandonment of writing tests first will become the accepted approach. As the pressure builds over time (in direct proportion to the decaying of the code base), more and more discipline will be forsaken as the project descends into a neverending cycle of putting out fires with band-aids.

Despite all of this, I still assert that structure does not produce behavior. While many people will succumb to the time pressure and choose the symptomatic "solution," others (perhaps those who have made that mistake before) will have the wisdom to choose a fundamental solution. That said, the structure of this situation will heavily influence the people involved, pushing them in the wrong direction. To truly attack this situation in a proactive manner, one needs to delve into the source of the time pressure and find points of leverage to alter the structure of the system (that will be left as an exercise for the reader :-).

So what happens to the band-aid bunch? Eventually they will hit rock bottom. Some people may lose their jobs. Or the company may go out of business. A question that I continue to ponder is how we can safely and effectively raise the bottom in order to stop the downward spiral before it does its eventual damage.

Update: David Greenfield and I had an email conversation yesterday that helped me clarify my thoughts on Structure and Behavior. As I was replying to one of his emails, something clicked:

David,

As I was responding to your email, something finally clicked for me.
I was hung up on the fact that a given structure would produce a given
behavior, irrespective to the person that was living within that
structure. In other words, if I was placed in a specific system, that
system would produce a certain behavior in me...and then if you were
placed in that same system, the same behavior would be produced.

But what finally got through to me is that the structure *will*
produce behavior, there is no arguing with that. It just might not be
the *same* behavior that would have been produced if someone else was
in that same situation.

Are we still in disagreement? I'm not sure.

--Dave

Posted by Dave [Link]

In November, I wondered how long it would be before test-driven development was considered mainstream. I believe it is probably the most likely candidate of any of the XP practices to attain "mainstream" status.

Today, I have spent some time learning about Spring. I was perusing a tutorial written last August when I read this and smiled:

"Actually, we probably should have written the tests first, but since this is a tutorial style document I think it makes more sense to introduce the actual code before the tests."

A completely technically focused tutorial mentioning TDD. It's creeping ever closer...

Posted by Dave [Link]

"While many professionals seem to stop learning as soon as they leave graduate school, those who become lifelong learners practice what [Donald Schön] calls 'reflection in action,' the ability to reflect on one's thinking while acting." (192)

Maintaining a mindset of lifelong learning has helped me tremendously. Earlier this year, Pat and I started up a distributed study group called Lifelong Learners. Some excellent relationships were formed even as the group's members began to get pulled away by other commitments (myself included). My hope is that the group will evolve and endure as we find other topics that will bring us back together periodically.

The above quote from The Fifth Discipline reaffirms that I want to read Donald Schön's The Reflective Practitioner, a book I first learned of when I read Alistair's dissertation [PDF]. Reflective Systems Development is another interesting book that relies heavily on Schön. Schön's work has even been directly applied to extreme programming [PDF].

Posted by Dave [Link]

[Archive Index] [Main Index]

Powered by Greymatter