Monthly Archives: April 2006

Studying Jeff Atwood’s Paint Can

Posted on by
2

I just found Jeff Atwood’s Coding Horror blog. He’s an interesting writer and thinker.

One of his postings presents a good example of the subtle role of skill even in highly scripted activities. He writes about following the instructions on a paint can. His article links to an earlier article, so you might want to read both.

The article is based on a rant by Steve McConnell in his book Rapid Development about the importance of following instructions. Steve talks about how important it is to follow instructions on a paint can when you are painting.

I want to talk, here, about the danger of following instructions, and more specifically, the danger of following people who tell you to follow instructions when they are not taking responsibility for the quality of your work. The instruction-following myth is one of those cancers on our craft, like certification and best practices.

[Full Discolosure: Relations between me and McConnell are strained. In the same book, Rapid Development, in the Classic Mistakes section, Steve misrepresented my work with regard to the role of heroism in software projects. He cited an article I wrote as if it was indicative of a point of view that I do not hold. It was as if he hadn’t read the article he cited, but only looked at the title. When I brought the error to his attention, he insisted that he did indeed understand my article and that his citation was correct.]

Let’s step through some of what Jeff writes:

“But what would happen if I didn’t follow the instructions on the paint can? Here’s a list of common interior painting mistakes:

The single most common mistake in any project is failure to read and follow manufacturer’s instructions for tools and materials being used.”

  • Jeff appears to be citing a study of some kind. What is this study? Is it trustworthy? Is Jeff himself telling me something, or is Jeff channelling a discarnate entity?
  • When he says “the most common mistake” does he mean the one that most frequently is committed by everyone who uses paint? Novices? Professionals? Or is he referring to the most serious mistakes? Or is he referring to the complete set of possible mistakes that are worth mentioning?
  • Is it important for everyone to follow the instructions, or are the instructions there for unskilled people only?
  • Why is it a “mistake” not to read-and-follow instructions? Mistake is a loaded term; one of those danger words that I circle in red pencil and put a question mark next to. It may be a mistake not to follow certain instructions in a certain context. On the other hand, it may be a mistake to follow them.

Consider all the instructions you encounter and do not read. Consider the software you install without reading the “quickstart” guide. Consider the clickwrap licenses you don’t read, or the rental cars you drive without ever consulting the drivers manual in states where you have not studied the local driving laws. Consider the doors marked push that you pull upon. Consider the shampoo bottle that says “wash, rinse, repeat.” Well, I have news for the people who make Prell: I don’t repeat. Did you hear me? I don’t repeat.

I would have to say that most instructions I come across are unimportant and some are harmful. Most instructions I get about software development process, I would say, would be harmful if I believed them and followed them. Most software process instructions I encounter are fairy tales, both in the sense of being made up and in the sense of being cartoonish. Some things that look like instructions, such as “do not try this at home” or “take out the safety card and follow along,” are not properly instructions at all, they are really just ritual phrases uttered to dispel the evil spirits of legal liability. Other things that really are instructions are too vague to follow, such as “use common sense” or “be creative” or “follow the instructions.”

There are, of course, instructions I could cite that have been helpful to me. I saw a sign over a copy room that said “Do not use three hole paper in this copy machine… unless you want it to jam.” and one next to it that said “Do not use the Microwave oven while making copies… unless you want the fuse to blow.” I often find instructions useful when putting furniture together; and I find signs at airports generally useful, even though I have occasionally been steered wrong.

Instructions can be useful, or useless, or something in between. Therefore, I propose that we each develop a skill: the skill of knowing when, where, why and how to follow instructions in specific contexts. Also, let’s develop the skill of giving instructions.

Jeff goes on to write:

“In regard to painting, the most common mistakes are:

* Not preparing a clean, sanded, and primed (if needed) surface.
* Failure to mix the paints properly.
* Applying too much paint to the applicator.
* Using water-logged applicators.
* Not solving dampness problems in the walls or ceilings.
* Not roughing up enamel paint before painting over it.”

Again with the “most common.” Says who? I can’t believe that the DuPont company is hiding in the bushes watching everybody use paint. How do they know what the most common mistakes are?

My colleague Michael Bolton suggested that the most common mistake is “getting the paint on the wrong things.” Personally, I suspect that the truly most common mistake is to try to paint something, but you won’t see THAT on the side of a paint can. As I write this, my bathroom is being repainted. Notice that I am writing and someone else is painting. Someone, I bet, who knows more about painting than I do. I have not committed the mistake of trying to paint my own bathroom, nor of attempting to read paint can instructions. Can I prove that is the most common mistake? Of course not. But notice that the rhetoric of following instructions is different if you draw a different set of lines around the cost/value equation represented by the word “mistake.”

Also, not knowing much about painting, I don’t understand these “mistakes.” For instance:

  • What is a clean surface? How do I sand it? What does “primed” mean and how do I know if that is needed?
  • How do I mix paints? Why would I even need to mix them? What paints should I mix?
  • What is the applicator and how do I apply paint to it? How much is enough?
  • What is a “water-logged” applicator? How does it get water-logged? Is there a “just enough” level of water?
  • How does one recognize and solve a “dampness problem”?
  • I assume that “roughing up” enamel paint means something other than trying to intimidate it. I assume it means sanding it somehow? Am I right? If so, how rough does it need to be and how do I recognize the appropriate level of roughness?

I am not kidding, I really don’t know this stuff.

Then Jeff writes:

“What I find particularly interesting is that none of the mistakes on this checklist have anything to do with my skill as a painter.”

I think what Jeff meant to say is that they have nothing to do with what he recognizes as his skill as a painter. I would recognize these mistakes, assuming for the moment that they are mistakes, as being strongly related to his painting skill. Perhaps since I don’t have any painting skill, it’s easier for me to see it than for him. Or maybe he means something different by the idea of skill than I do. (I think skill is an improvable ability to do something) Either way, there’s nothing slam dunk obvious about his point. I don’t see how it can be just a matter of “read the instructions stupid.”

Jeff writes:

“My technical proficiency (or lack thereof) as a painter doesn’t even register!”

Wait a minute Jeff, think about this. What does have to do with your proficiency as a painter? You must have something in mind. If proficiency is a meaningful idea, then you must believe there is a detectable difference between having proficiency and not having proficiency, and it must go beyond this list of issues. Rather than concluding that your skill doesn’t enter into it, perhaps one could look at the same list of issues and interpret it as a list of things unskilled people frequently do when they try to paint things that often leads them to regret the results. It’s a warning for the unskilled, not a message for skilled painters. A skilled painter might actually want to do these things, for instance, to paint with a water-logged applicator to get some particular artistic effect.

Jeff writes:

“To guarantee a reasonable level of quality, you don’t have to spend weeks practicing your painting skills. You don’t even have to be a good painter. All you have to do is follow the instructions on the paint can!”

Now I have logic vertigo. How did we get from avoiding obvious mistakes, where we started, to “reasonable quality”? Would a professional house painter agree that there is no skill required to achieve reasonable quality? Would a professional artist say that?

(And what is reasonable quality?)

Even following simple instructions requires skill and tradeoff decisions. A paint can is neither a supervisor, nor a mentor, nor a judge of quality. Don’t follow instructions, instead I suggest, consider applying this heuristic: instructions might help.

And one more thing… Does anyone else find it ironic that Jeff’s article about reading instructions on paint cans would include a photo of a paint can where the instructions have been partly obscured by paint? Perhaps the first instruction should be “Check that you see this sentence. If not, please wait for legible instructions.”

Defining Agile Methodology

Posted on by
11

Brian Marick has offered a definition of agile methodology. I think his definition is strangely bulky and narrow. That’s because it’s not really a definition, but an example.

Those of us who’ve worked with Brian know that he doesn’t like to talk about definitions. He’d rather deal with rich examples and descriptions than labels. He worries that labels such as “Agile” and “Version Control” can easily become empty talismans that can turn a conversation about practice into a ritualized exchange of passwords. “Oh, he said Agile, that must mean he’s one of us.” I admire how Brian tries to focus on practice rather than labelling.

Where Brian and I part ways is that I don’t think we have a choice about labels and their definitions. When we decline to discuss definitions we are not avoiding politics, we are simply driving the politics underground, where it remains insidious and unregulated. To discuss definitions is to discuss the terms by which your community governs itself, so that we do not inadvertantly undercut each other.

Here’s an example of how postponing a conversation about definitions can bite you. A few years ago, at the Agile Fusion peer conference I hosted at my lab in Virginia, Brian and I got into a heated debate about the meaning of the word “agile”. He said he was completely uninterested in the dictionary definition. He was interested only in how he felt the word was used by a certain group of people– which group, it turned out, did not include me, Cem Kaner, or very many of my colleagues who can legitimately claim to have been working with agile methodologies since the mid-eighties (or in one case, mid-sixties). Perhaps because of Brian’s reluctance to discuss definitions, our disagreement came up out of the blue. I don’t know if it surprised Brian, but it shocked me to discover that he and I were operating by profoundly different assumptions about agile methodology.

Actually, I have had many clashes with people who claim to own the word agile. It’s not just Brian. But some agilists in the capital “A” camp don’t limit themselves to it. Ward Cunningham is a great example. Find Ward. Meet him. Talk to him. He gives agile methodology a good name. I have had similar positive experiences with Alastair Cockburn and Martin Fowler.

There are at least two agile software development communities, then. My community practices agile development in an open-ended way. We support the Agile Manifesto (in fact, I was invited to the meeting where the manifesto was created, but could not attend). However:

  1. We do not divide the world into programmers and customers.
  2. We do not demand that everyone on the project be a generalist, and then define generalist to be just another word for someone who remains ignorant of all skills other than programming skills.
  3. We believe there can be different roles on the team, including, for instance, the role of tester; and that people performing a role ought to develop skill in that art.
  4. We don’t limit our practices to fit guru-approved slogans such as “YAGNI” and “100% automated testing”, but instead use our skills to match our practices to our context.
  5. We don’t accuse people who question practices of “going meta” as if that is a sin instead of ordinary responsible behavior.
  6. We aren’t a personality cult. (if you ever hear someone justify a practice by saying “because James Bach said so” please email me so I can put a stop to it. I like being respected; I hate being a blunt object for ending a debate.)
  7. We don’t talk as if software engineering was invented in 1998.
  8. We question. We criticize. We learn. We change. We are agile.
  9. When we make definitions, we strive to be inclusive and try not to redefine ordinary English words such as “pattern” or “agile”. Specifically, we probably won’t say you just don’t “get it” if you cite the dictionary instead of using approved gurucabulary. GURUCABULARY: (noun) idiosyncratic vocabulary, often a redefinition of preexisting words, asserted by one thinker or thinkers as a way of establishing a proprietary claim on a field of interest.

I want to offer an alternative definition for use outside of the insular world of capital “A” agilists.

First, here is the Websters definition of agile:

agile
Function:adjective
Etymology:Middle French, from Latin agilis, from agere to drive, act, more at AGENT
Date:1581

1 : marked by ready ability to move with quick easy grace *an agile dancer*
2 : having a quick resourceful and adaptable character *an agile mind*

Here, then is my definition of agile methodology:

agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.

A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.

Brian Marick’s definition of agile methodology is an example of how one community approaches what I would call agile methodology. My definition is intended to be less imperialistic and more pluralistic. I want to encourage more of us to explore the implications of agility, without having to accept the capital “A” belief system whole.

Fight the power!

“Use Version Control”

Posted on by
Reply

Darrell Norton says that “version control” is a best practice. I disagree with him about that, but his blog posting gives me an opportunity to show how context-driven reasoning works.

Darrell writes:

“If you’re looking for a No Best Practice rant like James Bach, then you won’t find it here. Instead, here I will propose the one true best practice I’ve found, one which I have not been able to change it from being a best practice no matter how much of the situation I change:

Use version control”

I think that’s the whole message. I was not able to find any more to it. Okay, let’s look at this critically. I wrote a blog entry about no best practices. Questions that immediately occur to me are the following:

  1. What is the practice being proposed as best?
  2. From what field of candidates has it emerged as the best?
  3. By what sorting process has it been determined to be best?
  4. In what contexts does that sorting process apply?

These questions are not answered in his message, nor does he point to any resource by which we may answer them. I’m concerned about that, because while Darrell may not be a pointy-haired boss who bullies people with nonsensical process-speak, some of that pointy hair in the world does read blogs. Such people latch onto things they don’t understand and force feed them to people who would otherwise be free to do their work in peace.

I am willing to believe that Darrell has some idea in his mind to which he has applied the label “version control”, and he has some notion of what it means to “use” it. I suspect that, to him, this practice seems obvious, and the contexts in which it is worth doing is obvious, too.

But whatever it is Darrell has in mind is not obvious to me, and I’ve been in this business a long time, both as a programmer and in other roles. Darrell has not explained what he means by version control. He has essentially flashed us a briefcase marked “version control”. I wonder what is in that case?

I’ve used something I would also call “version control”, but it isn’t any one thing, it’s many things. One form of version control I’ve used might be called “your turn, my turn”. In YTMT version control, you work on something for a period of time, then you email it to someone else to work on. You don’t touch it until he emails it back to you. Tada! Version control. Is that what Darrell meant? Is that “best”?

I’ve also used Visual SourceSafe. Some would say that’s a terrible tool, others, I suppose, swear by it. Either way, SourceSafe does not solve all the problems of controlling versions. There must be more to the practice of version control than buying a tool and installing it.

I can list many more humble practices that comprise version control for me, and each one involves a choice, not only about what to control, but also about what need not be controlled. Version control goes hand-in-hand with version un-control (e.g. I might change the version number of the document occasionally, yet not keep track of each individual change, and that might be good enough version control).

In many contexts, such as developing complex production software, version control deserves attention. It does not deserve to be patronized by the phrase “best practice.” I think, in his effort to elevate it, Darrell has inadvertantly degraded it to a slogan. He has elevated an empty husk.

Fortunately, he can fix it. All he has to do is tell a story about a time before he practiced “version control” and some problems he suffered. Then he should share how a specific practice of version control (he must describe this enough so that we can get a mental picture of it) seemed to solve those problems without creating too many new ones. We, the readers, would then decide for ourselves what his experience has to do with our own contexts.

While I deny that there can be an unqualified best practice, I have personally experienced benefit from hearing stories about how other people have solved specific problems by employing some practice or another. I think we need more stories, and fewer slogans. Please help.

Therefore, in the spirit of self-referential humor, I say to you “No Best Practices!”

Some Useful Definitions

Posted on by
1

I use the following. I find these definitions to be flexible, inclusive, and consistent with the dictionary:

Technique: method.

Method: a way of doing something; an idea or ideas that specify behavior.

Methodology: a system of methods.

Approach: a way of enacting a method; a characteristic pattern that modifies method. E.g. “the stress testing technique may be performed using either a scripted or exploratory approach”

Practice: what somebody actually does; a way of doing something that someone actually uses. (usage note: a method is a practice only in the context wherein someone uses that method)

Process: how something happens; a causally-related chain of events. (usage note: a practice or method may describe or affect a process, but process encompasses the totality of events, not just the parts that people might do or think of themselves as doing)

Test technique: test method; a heuristic or algorithm for designing and/or executing a test; a recipe for a test.

Test strategy: the set of ideas (i.e. methods and objectives) that guide test design and execution.

Test logistics: the set of ideas that guide the application of resources to fulfilling the test strategy.

Test plan: the set of ideas that guide a test project; the totality of test strategy and test logistics. (usage note: A test plan document does not necessarily contain a test plan, and a test plan may not necessarily be expressed in written form. Beware confusing a genuine test plan with a document that merely has “test plan” as its title.)

Testing: questioning a product in order to evaluate it (Bach version); technical investigation of a product, on behalf of stakeholders, with the objective of exposing quality-related information of the kind they seek (Kaner version).

Test Idea: an idea for testing something.

Test: a particular instance or instances of questioning a product in order to evaluate it; or a document, artifact, or idea that represents such a thing.

Test case: see Test