Mike Kelly’s blog

A while ago, I read David Galenson’s “Old Masters and Young Geniuses: The Two Life Cycles of Artistic Creativity.” This book was appealing to me because I use to be an art student and I’m always looking for books on creativity, but as I read it I started to see patterns in it that lead see the Old Masters and Young Geniuses metaphor as something useful for software testers. If you often find books that have nothing to do with software testing, useful in helping you form your opinions about software testing, then I think you’ll enjoy this book immensely.

Disclaimer, I only read the book once, so some of my summary statements might be a little off, but for the most part, I think I do it justice. I might have miss-read something here or there. Don’t be too upset if I got something wrong.

In the book, Galenson draws the distinction between the experimental and conceptual artist. The experimental artist is the artist who works in a very controlled fashion; almost scripted. They make variations to their process and practice over time, but always in a calculated way. Always trying to perfect some small aspect of their craft. They might do the same work, or series of works, over and over again. Think of Monet as an archetype of the experimental artist. Galenson tries to illustrate that the experimental artist’s best work is done late in their career. They become an “Old Master.”

The conceptual artist is the artist who works more from intuition then from process. They break from custom. They do something never done before of take some established philosophy and turn it on it’s head. The might do a particular work or even style only once, and move on to the next phase of their career. Think of Picasso as an archetype of the conceptual artist. Galenson tries to illustrate that the conceptual artist’s best work is done early in their career. They start as a “Young Genius.”

Interesting dynamics emerge in the differences between the way the two groups work:

“The distinction between experimental and conceptual artists can be sharpened by considering their procedures in making paintings. For this purpose, we can divide the process into three stages: planning – all the artist does before beginning a particular painting; working – all the artist does while in the process of putting paint on the canvas; and stopping – the decision to cease working.”

Galenson explains that for the experimental, all three stages are controlled. Extensive upfront planning takes place, work is tightly controlled (often delegated), and the decision to stop is predicated on completion of a goal. For the conceptual, there is little to no planning; that stage is very short. The “signing” artist does most work, and the process for the work may vary day to day. The decision to stop is heuristic.

As I read the book, I found myself inserting scripted for experimental and exploratory for conceptual. Think of a continuum like the scripted vs. exploratory continuum (you can see an example on slide 15 of Jon Bach’s Breaking Down Exploratory Testing Skill talk) many of us use to illustrate the continuum for testing. In a similar continuum for artists, you might have those that tend to favor small controlled change, with learning over time, and those that favor large rapid change, with breakthrough results. It’s a stretch, and it doesn’t fit perfectly throughout the book, but it was useful for me. This book changed the way I view the dynamic between the two polarities.

“Recognizing the differences between the experimental and conceptual approaches provides the basis for systematic predictions concerning the relationship between age and artistic innovation. The long periods of trial and error often required for important experimental innovations means that they will tend to occur late in an artists career. Because conceptual innovations are made more quickly, it might be thought that they should be equally likely to occur at any age. Yet the achievement of radical conceptual innovations depends on the ability to perceive and appreciate the value of extreme deviations from existing conventions and traditional methods, and this ability will tend to decline with experience, as habits of thought become more firmly established. The most important conceptual innovations should therefore tend to occur early in an artist’s career.”

With this prism, if I view an early book on software testing, or an exemplar from the factory school, I might choose to see someone who is trying to perfect a method of their craft. With small controlled changes, they might make that method a little bit better each time. If I view an article on exploratory testing (because there aren’t many books dedicated to the topic), or an exemplar from the context drive school, I might choose to see someone who is trying to revolutionize the field. Someone with the “ability to perceive and appreciate the value of extreme deviations from existing conventions and traditional methods.”

This is important, because for me it creates a place where I can appreciate the innovations one might want to make within a school that isn’t the one I choose. I sometime struggle with that; this helps. Don’t get me wrong, I think there are exploratory testers who are old masters (James Bach?) and scripted testers who are young geniuses (Kent Beck?) within their particular school. Like I said, it’s a model…

After I read that last large quote in the book (”Recognizing the differences between…”), a couple of questions occurred to me. I wrote them down in my moleskin and wanted to explore them here.

First, I’ve heard Cem Kaner talk about our field’s problem of not learning from history. To paraphrase what I think the problem is, software testers (computer scientists in general?) don’t invest much time in learning the history of their craft. Does this continuum relate in some way to that history problem?

I think it’s possible that, of those that are “aware” – I suspect some testers don’t want to be young geniuses or old masters, most would rather be conceptual, and thus don’t think they need to understand history to make a meaningful contribution. Thus, like many artists, they may make (and probably often do) an “original” contribution that was original 20 years ago. In addition, if most old masters really are old (in terms of how long they have been practicing their craft), and if a solid understanding includes understanding past history, and many testers leave testing for career changes, project management, BA roles, programming, or some other development role, can we even develop old masters?

Second, if I look at someone whom I think might fit the young genius mold, Jon Bach, what are the implications for how I can learn from the behavior I see? (I choose Jon as my example because of the work he did early in his career with session based and open book, two ideas that I think are conceptual innovations in our field. Jon, I hope you don’t mind.)

If I look at examples of young genius in testing (or old masters), just as I could in art, what could I learn personally to influence how I become conceptual (or experimental). What are the implications for me (or for anyone who wants to innovate – either drastically or a little bit over time)?

Finally, in the book, Galenson provides some models for measuring the success of a work of art. I won’t go into them here, but imagine if we had a way to measure the success of a testing idea. It wouldn’t necessarily tell you it if was good, just like you can’t look at the popularity of a painting and say that makes it good, but it tells you it was potentially influential is some way. How would, or could we, measure the influence of testing ideas?

Most of those questions are rhetorical. I’m not really expecting anyone to answer. The book just got me thinking. It has some great stuff on schools and movements, analytic techniques, developing intuition, community, and a ton of stuff on the exploratory process. Recommended read.

The December issue of Writer’s Digest has some great articles on creativity in it. One in particular caught my attention: Blinded by the Light by Leigh Anne Jasheway-Bryant. In the article Leigh Anne provides tips for overcoming Too Many Ideas Syndrome. It’s a problem many testers face. I think all nine tips can be applied to testers who have to deal with managing all the test ideas they have in their head.

Meeting of the Minds by Michael J. Vaughn and Mapping Out of a Block by Greg Korgeski are also very applicable to what we do as tester. Three great articles for that look at techniques for generating/elaborating, roughing/refining, and refocusing.

Pick up the December issue if you don’t already get Writer’s Digest. (And of course, what tester doesn’t already get Writer’s Digest?)

Alter Ego written by Dave Christiansen has just been published. I was one of the reviewers for the book and I think it’s an excellent read. It has (almost) nothing to do with testing, but it’s a great read for geeks who like fiction with a technology twist. And it is twisted!

Read it. You won’t regret it. (You can even preview the first six pages online…)

Last year I read Behind Closed Doors: Secrets of Great Management by Johanna Rothman and Esther Derby. The book is well written and is told in an interesting way. In the back of the book, there is a section titled Techniques for Practicing Great Management. In that section, I found a list of questions designed to help managers make the progress of any project contributor more visible. You might try asking questions like the following:

• How will you know when you’re done with that?
• What steps will you take?
• Which part will you work on first?
• Can you provide a picture or a measurement of work to date?
• Do you need to collaborate with anyone else on this?
• How will you know you’re making progress?
• Who needs to be in the loop if you are unable to finish this on time or run into problems?

When I finished reading this list, I noticed that some of these questions were eerily familiar. In fact, a past manager had asked me those questions before. I remember thinking about why he would be asking me those questions because I always report my progress.

After reflecting on the questions a bit more, I began to recognize that I had not been effectively communicating my progress. Without even being aware I was doing it, I had stopped. Not only have I not been communicating progress, I haven’t even been telling my manager what I’ve been working on.

I see three reasons as to why this might have been:

1. I didn’t yet really understand the scope of the work I was doing. I knew what I wanted to do, and I knew how I wanted to do it, but I was still trying to work out the steps to get from point A to point B. Because I didn’t truly understand the work yet, I couldn’t think of a way to explain my tasks to my manager yet. When he asked what I’d been doing and what I planed to do, he was looking for a level of precision that I just didn’t have yet.

Mark: “Which part will you work on first?”

Me: “I don’t really know what the parts are yet. I’m still trying to figure that out.”

Mark: “How will you know when you’re done with it?”

Me: “I don’t know yet. I’m still not sure what ‘done’ means. It’s a complex set of tests and I still don’t know what they will look like.”

Mark: “Do you need to collaborate with anyone else on this?”

Me: “Of course, I just don’t know who yet.”

As you can see, I was very vague.

2. My manager was new (to me). The old manager just rolled off the project and this manager had not yet been ‘tested in battle.’ We didn’t yet have a history or a working relationship. It’s hard to develop a working relationship with a new manager. We didn’t know to communicate yet and we both had different expectations for what the person in our roles should be doing.

Therefore, much of what he asked me smacked of micromanagement. When in truth, it was more likely that he truly didn’t know what I was doing and he was just trying to learn the only way he knew how - asking questions. Nothing wrong with that…

3. Finally, I was moving off the project in the near future (or at least my status with the project was rapidly changing). That meant that I didn’t really want to take the time to build the relationship like I normally would have. It’s hard work getting to know how to work with someone new and I just didn’t want to put in that effort.

Once I recognized my behavior, I needed to fix it.

Starting the Monday after I finished the book, I took the time to invest in the new relationship. It was not his fault he was new, I was just being silly (to put it nicely). I worked with him to provide more visibility to my tasks and progress. I struggled with him to understand the work. I included him in my brainstorming sessions and talked with him more about the nature of the testing I was planning.

Oddly enough, that process of explaining it to someone else helped me better understand the problem. The investment was worth it.

To build on the idea of effortful study, I found the following in this month’s FastCompany in the article The Expert on Experts: An expert guide to expertise by Christopher Percy Collier.

Some excerpts of an interview with K. Anders Ericsson, Professor of Psychology, Florida State University:

“With the exception of some sports, no characteristic of the brain or body constrains an individual from reaching an expert level.”

“Elite performers engage in what we call ‘deliberate practice’–an effortful activity designed to improve individual target performance. There has to be some way they’re innovating in the way they do things.”

“In general, elite performers utilize some technique that typically isn’t well known or widely practiced.”

“You have to seek out situations where you get feedback.”

The article references The Cambridge Handbook of Expertise and Expert Performance. Amazon has indicated that it would be happy to ship said book to my house. It’s big, so give me time for a full report.