I would like to announce that Manning Publications has begun sending its books to Safari Online, the subscription-based O’Reilly service. I have found the service useful over the past three years, particularly after our flood wiped out much of my professional development book collection. If you subscribe to the service, but have not yet read JUnit Recipes, you will soon have your chance!

I ran across Cédric Beust’s article Agile People Still Don’t Get It again, and I just wanted to point one little thing out for you, for him, for everyone. He writes about a presentation he attended that illustrated why agile people still don’t get it:

One of the first slides that deeply troubled me claimed the following: Tests are (executable) specs; (and) If it’s not testable, it’s useless.

Cédric went on to show a number of examples of algorithms that aren’t worth test-driving and useful code that isn’t testable. All very good, all understood, all makes sense; but all in his acerbic, off-putting style.

Cédric, I love you like a brother, but this Bileblog nonsense is wearing thin. We’re not 21 any more; and it’s time to reach a wider audience of more thoughtful people through sensible and reasonable discourse. I’m afraid that, in this case, your conclusion does not at all follow from the hypothesis.

It’s true that there is a steady supply of agile evangelists out there that push agile like a religion, but not only is none of this is news, but it’s a natural part of the evolution of any idea. I went through my proselytizing phase. It was at a time when my primary concern was getting to practice agile, and I thought that if more people liked it, more people would give me the chance to practice it. Instead, I started taking myself more seriously as a business person, made more money, and that has translated to more free time to practice whatever I want to practice. This allowed me to feel more secure about my own agile practice and my own effectiveness as both a practitioner and consultant. Not everyone takes the lead in their careers like I did, so when you see someone lashing out, proselytizing, don’t hate them, but help them. There’s something missing in their lives, and it’s worth offering them a chance to find out what it is and fill the void. People did that for me, and I’m willing to do that for others. Are you?

On the question of the agile religion, you might think Bob Martin is one of the High Priests of Agile, but as early as 2002 (!) he warned us about this behavior, and I take away two key points from his message. I believe it was at a dinner talk at XP/Agile Universe 2002 that he invited us not to make absolute statements about agile.

Those absolute statements served us well to rile up the visionaries (in the Crossing the Chasm sense), but as we reach the mainstream, statements like these hurt more than they help. I prefer to tell people that the more they test, the better their features are; and the more testable their features are, the more easily maintained they are. They seem to respond to that, especially when I show them how that is. I still astonish people, as unexpectedness is a key component of a sticky message, but I prefer not to use divisive, absolute rhetoric to do that. I use different techniques for that now.

I believe it’s become more important to be less overtly provocative, and instead be clearer with our advice. I don’t think most thoughtful agilists will claim that they write production code the way they teach others to do it; but this is not a simple case of “do as I say, but not as I do”, but rather a case of the student needing to learn the lessons by following some useful rules before leaning too much on under-developed judgment. Not everyone agrees that we should give novice rules to novices, but it works well for me, so I do it. This means that I sometimes tell people “delete that code because it isn’t tested” or “stop and refactor the code until it’s testable”. I find it an effective way to help them learn and develop judgment, the skills I believe will serve them best. I tell my students directly:

Do I take tiny steps like this every time I write code? No. Do I think you should take tiny steps like this when you write code? Yes. Why? Not because it’s the best way to write software, but because you learn a lot when you do it and, more importantly, when it’s 2 AM, you’ve been called back from vacation, you’re performing surgery on a production system that’s losing $100,000 per hour of downtime, you’ll be glad you can work in such small steps.

More succinctly, I’m more up-front with people about the pedagogical aspects of what I do. They seem to respond well to that, rather than patting them on the head and saying, “No, trust me, just write the tests. You’ll learn.” I’m sure there are plenty of trainers out there, agile and otherwise, who treat their students like children, rather than adults. They make absolute statements of the type that Cédric is right to complain about. I just wish he wouldn’t make it seem like a uniquely agile problem, and I wish he wouldn’t lump us all in one bucket. I suppose it’s convenient to do that, but it’s not true.

In fact, it feels downright religious to do so.

I prefer not to rant on this weblog, because I don’t find ranting very becoming; however, there are a few hot-button issues that I want to rant about, and so here it is. I promise it will be brief.

I know, like and respect Reg Braithwaite-Lee, who writes here. Frankly, I don’t understand everything Reg writes about, but I love his enthusiasm and I often learn from him. All the more reason, then, for this to annoy me. Recently, he wrote:

I have now received my second request for an RSS feed that does not include a daily summary of links I find relevant to this weblog. So I’m thinking about dropping them outright.

I’m not thinking about offering three feeds (one just links, one just posts, and one blended). I’m not even thinking about offering two feeds. There is one feed for this weblog; the question I am asking myself is whether it should contain my words or whether it should contain my words and a daily summary of interesting links.

To be blunt for a moment, this chaps my ass. To the two people who made this request to Reg, did you read your own e-mail before you sent it? This is what you’re asking Reg:

I know you offer us a lot of useful information and opinion, and I know I don’t have to pay a dime for it, but would you please customize my experience by doubling your effort so I can avoid having to press Delete?

You want a custom experience? Offer to pay for it. If you can’t hit delete once per day because you don’t find Reg’s del.icio.us links interesting, that’s fine; but if you expect Reg to rearrange his writing for you, then you should offer to pay him. I find it the height of arrogance to ask someone to do more work without offering him something in return.

If I were Reg, I would, after calming down, politely decline the request. If I were to act without calming down, I would think along the lines Reg is thinking, and reduce my output to the lowest common denominator. And my readers would likely lose, on the whole.

So Reg, to hell with those two people. I find 90% of your del.icio.us links to be a waste of time, but every week or so I read something I’m glad I read. Funny… it’s like I read something about that somewhere recently.

Updated November 9, 2007. Read more about this here]

Sometimes, in the middle of a long, drawn-out discussion, someone says something that cuts to the heart of the matter, or some portion of it. I usually find it refreshing, and I love it, even when I’m not the one saying it. I just read one and would like to share it.

I think that there is one kind of business value, profit.

It’s funny, but funnier in context. Click the title of this entry to read the entire thread, but only if you have some energy to spare.

Some colleagues have drawn my attention to this, from an MSDN article:

Although the idea of code coverage is simple enough, actually performing code coverage analysis in a non-.NET environment can be very time consuming, difficult, and expensive. (Source)

Ignoring for a moment whether the statement in the article is true, it’s pointless, because it sets up a comparison without describing what it’s comparing to. It’s a vacuous statement masquerading as a fact. This is the worst kind of writing.

There are several reasons this statement is valueless:

1. Even if performing code coverage analysis can be expensive, that doesn’t mean it must be expensive. Almost anything a person might do could be expensive, if done poorly enough.
2. Performing code coverage analysis can be relatively easy and cheap. I haven’t done it in a while, but the last time I set up a project with Maven I got code coverage analysis free of charge, and it only took me a half-day to learn and do. Not free, but relatively cheap, considering everything I get for my investment of a half day.
3. The author cites nothing to support this statement, making an opinion (debatable) look like a fact (not up for debate).
4. Later, the author writes “In the days before .NET, code coverage was one of the most frustrating parts of my job as a tester.” On which platforms? In which contexts? At least tell us a story to entertain us. Maybe you were an idiot back then and you’re smarter now, and your current self would have been able to easily perform code coverage on that project.

I could go on, but I believe you get the point.

Let me be clear: I don’t mean to say that one shouldn’t try to express one’s opinion in the best possible light; and I don’t mean to say that one ought not to promote one’s work. I do both. Still, when one writes, one needs to remember to separate opinion from fact and one needs to support one’s opinions with at least one concrete anecdote to give the reader an idea that one is not simply talking out of one’s ass. To do any less is to show an astounding lack of respect for one’s readers.