Rhythm and Reality

I was a bit "under the weather" recently. I was thinking about a lot of things. One of them was rhythm.

I teach drumming, private lessons, group lessons and workshops. Rhythm is a big deal for drummers. Its kind of what we do. So, I went looking for how rhythm is defined by "non-drummers." So I went to the web.

I went to freedictionary.com and found this:

1. Movement or variation characterized by the regular recurrence or alternation of different quantities or conditions.
2. The patterned, recurring alternations of contrasting elements of sound or speech.
3. Music
a. The pattern of musical movement through time.
b. A specific kind of such a pattern, formed by a series of notes differing in duration and stress: a waltz rhythm.
c. A group of instruments supplying the rhythm in a band.
4.
a. The pattern or flow of sound created by the arrangement of stressed and unstressed syllables in accentual verse or of long and short syllables in quantitative verse.
b. The similar but less formal sequence of sounds in prose.
c. A specific kind of metrical pattern or flow.

You get the idea, no?

Repeated patterns. Repeated actions. Repeated behaviors.

Have you noticed a repetition in projects or test efforts? Things keep coming back - almost like deja vu?

If things are working and "the process" is cracking-on, there are no problems. Right? No worries - you've got it down.

If things are, not-so-good - then what? Are your projects sounding a bit repetitious? Are they following the same model or are there slight variations in them? Is the "this could have been better" project from a year ago a role model of current projects or a warning for how future projects may go? Are things muddling along or are they getting worse?

If they are getting worse, why? Did the "lessons learned" sessions from the previous projects get acted on? Have your "process changes" been carried through and embraced by all particpants or by only some? If you're like me, you've worked in shops where that pretty well sums up the situation.

I remember one shop where I worked some time ago. They had beautiful documentation. Lots and lots of process. This happens - then this happens - then this happens. The Certified Project Managers pushed the Best Practices and Industry Standards to a fare-thee-well. They kept tight control over their progress meetings ("This is an update meeting, not a working meeting. If you need to discuss it, do so in a meeting other than this one.")

Projects were regularly train-wrecks.

All the participants made a great show of "following the process." Except they only went through the motions. It was an elaborate charade - they dutifully attended every meeting and carefully reported what was done and what needed to be done.

When the whole team really does what they were say they do, magical things can happen. One cynical... not nice person... can completely derail the project.

What I learned there, was to ignore the rules. When we projects focused on what needed to be done, and forced the "process" to that end, amazing things could occur. When the "process" drove the steps needed, the project failed.

There was rhythm in both cases. Its just one looked good on paper, the other looked messy - but it had a good beat and you could dance to it.

Good Morning, Tester-Land!

My name is Pete Walen - Welcome to my blog!

I do software testing for my profession. I am not a "world famous testing guru." I'm just a working stiff who is a practitioner and student of software testing.

I am also a drummer. I've been learning, playing, performing and teaching drumming for far longer than I've had anything to do with software.

I started drumming when I was in elementary school. I learned the same basics that most beginners learn. Like many school-trained drummers in the US, I played with the elementary/middle school band program, I also struggled with solos - playing them for judges and the like. I played in high school band programs - concert and marching band. Somehow my parents always were able to find me a teacher for private lessons so I could improve beyond what the school did.

I migrated to drum & bugle corps in high school. And youth symphony. And collegiate music programs led me to other ideas and approaches and techniques. I played in pick-up groups playing blues and jazz and rock and.. who knows what all. I spent a semester studying in Ireland where I learned yet another form of percussion - the Irish bodhran.

Something happened along the way. When I was in college, I was asked if I would consider teaching privately. That seemed perfectly normal at the time and I could use the extra cash. What student couldn't?

What was different for me was that one of my teachers had the wisdom to know that there could be many paths to achieve the same goal. If I was not understanding something, he very patiently went through the topic from scratch - explaining it in a totally different way, following a different path. When I began teaching drumming, I remembered that lesson and applied it with my own students.

After college, shortly after I started my first "real" computer job (programming COBOL for IBM mainframes) I discovered bag pipe bands. I was too old to play in drum and bugle corps. While teaching beginners was rewarding to some extent, with pipe bands I could still drum! It was also something else to learn and master. I joined the local band and have been involved in some form of drumming with pipe bands since the early 1980's.

These many years of drumming have led me to find rhythms in interesting and unusual places. In the more "usual" places, I hear rhythms not everyone else hears. When I'm playing music, I oftentimes bring those rhythms out in my drumming.

What are rhythms? They are patterns - ideas and concepts that can be found in the expression of music. Like any form of pattern, they can be found in other places as well. Typing on a keyboard gives a specific rhythm that can be identified. Seams in the pavement while driving to work gives an audible rhythm that sometimes mixes with the windshield wipers.

I used to see patterns in code when I was writing software applications (lo, those many years ago) and now I see patterns in applications when testing. There are rhythms in the way each person works. They can be unique unto themselves or they can be shared and common rhythms across teams or groups. Muggles refer to this as "group dynamics." They really are a rhythm (don't tell the muggles.)

My intent, therefore, is to use this space to talk about testing and other topics related to software, and the patterns and rhythms I see and hear and participate in around me.