Red Squirrel Reflections Dave Hoover explores the psychology of software development

[Previous entry: "TDD creeps closer..."] [Main Index] [Next entry: "Don't Hide Your Ignorance"]

Structure and Behavior Revisited
Wednesday, July 14, 2004

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

Replies: 1 Comment

>>Despite all of this, I still assert that structure does not produce behavior.

I think you are just plain wrong. I recommend "The Tipping Point" by Malcolm Gladwell, in which, he zeros in on exactly this question with a group a seminary students preparing for a talk on the Good Samaritan parable. Very very enlightening. Basic takeaway: context governs behavior.

Posted by david greenfield on 07/15/2004

Powered by Greymatter