I love your point about applying my experience to stories told by others; it’s a very good one and drives home the root of the discrepancies in our points of view. Taking blogs or even books written about peoples experiences with practices as factual source material is flawed (shockingly you can’t believe everything you read on the internet). On the other hand disregarding experiences reported over and over (widely accepted best practices) without trying them just because they don’t immediately makes sense also seems flawed (to me at least).

It’s possible that something needs to be tried to fully understand its benefit, right? Back to the first hand again; that doesn’t mean I think we should all drink the cool-aid in preparation for pickup by the mother ship, no matter how widely accepted it is. Clearly some sort of critical eye needs to be applied (My mom would love this “If your friends all jumped off a bridge…”, but I digress).

Source of the story, credibility of the author and level of acceptance in the community are elements that help us decide what parts of which stories to trust, but in the end we all decide for ourselves. I think I understand you better now, or did I miss the mark?

[James’ Reply: Yeah, that’s what I was trying to get across. Thanks.]

All that said, I admit that I may have an overly developed sense of respect for “authority”. Thanks for taking the time to discuss it with me.

[James’ Reply: There are certain authorities I respect, too. A pre-requisite for my respect is that each of these authorities, such as Cem Kaner or Jerry Weinberg, respects context and personal responsibility. That is part of what qualifies them as authorities for me. As they taught me to distrust authority, I pass that on to my own students, and teach them to distrust me.]

I’m clearly having trouble doing so. I intended the imagery to be more abstract than it came out, let me try and put it aside.

I read blogs (and books like yours to learn about what others are doing. Why do I even care? Well I’d like to know what has worked and not worked for others. I can then take that information and use it to help guide my processes. Industries frequently aggregate this concept into “best practices”. My point, at it’s heart, is that there is value in knowing what has worked for others. So I believe it’s valuable because it represents real experiences of real people. It’s not the only set of successful experiences out there, but it’s one.

[James’ Reply: I don’t have access to real experiences of real people, except by personal observation. Even then I perceive only part of it. I perceive only part even of my own experiences.

I bring my previous experiences and understanding to bear upon the stories I am told. If a man tells me that creating thousands of detailed procedural test cases worked for him as a great way to test, I treat that with a similar level of doubt as I would treat a story about using prayer to stop a hurricane.]

Knowing when to apply that knowledge and when to ignore it is the interesting question you’ve raised for me. You seem to fall heavily on the side of ignoring it. It sounds like that’s because you want to be an innovator. That’s great, I applaud you and will read about your experiences (and apply them to my projects as appropriate). I’m not sure that it’s desirable for every project that everyone works on to be innovative.

[James’ Reply: No no no. It has nothing to do with innovation. It has to do with responsibility. When you “apply my experiences”, you better not be numbly copying me. You better be interpreting and making sense for yourself.

While I do refuse to follow, I also do not ignore what colleagues have to say.]

I hear you. I’m thinking the junior software guy, the flying student, the writing student, need to master the best practices of their respective arts before they can understand their context well enough to leave dogma behind.

[James’ Reply: There are no best practices, so that advice has no meaning for me. Speaking as a pilot, the practices by which I flew were part of my supervised training process, the focus of which was to develop my skill and judgment, not to make me “follow best practices.” I was under the care of a qualified flight instructor during this process.

I reject the idea that expertise is best developed by moving from “following rules” to breaking them. I don’t know who came up with that theory, but an alternative theory is called constructivism. Constructivists like me develop expertise through personal experimentation. This is largely how I learned to fly– starting with a flight simulator.]

Furthermore I personally was wondering for myself if I’m at the stage where I can move beyond best practices given my context (A question each of us should probably ask once in a while). My feeling is yes, but then I imagine many martial arts students probably think they are ready to take on the master. Only by doing so and being soundly beaten do you realize you’ve got more to learn. I’m going to try to avoid the beating.

[James’ Reply: Avoid the beating; avoid the learning. In any case, I repeat, there are no best practices. I don’t know who your sensei is, but he’s putting you on if he says there are best practices.]

Fundamentally I like to be clear that I’m not disagreeing with your original points; taking a didactic attitude with professionals isn’t helpful. Telling people that they will fail without some dogmatic practice(s) is silly. Appointing oneself as the intellectual guardian of a methodology does not make it so. My final point is that his attitude doesn’t make the material itself less valuable.

[James’ Reply: But why should I believe that material IS valuable in the first place? Can you make that point without appealing to ephemeral authorities?

Let me put it this way: innovation can only happen when someone decides they have the right and responsibility to use their OWN judgment.]

To me, part of the context we’re talking about is the individual who is in that context. However at that point, as the person in the context, how can I possibly judge?

[James’ Reply: We can talk about experiences, problems, dynamics, values. There are lots of things we can talk about. If there are times when engineering needs dogma, I’d like to hear about it. I’m pretty sure dogma means uncritical submission of the mind. That’s not easy to defend.]

No, but I believe it is generally a bad practice. Just as I believe unit testing and refactoring generally good practices. And if people have never tried them personally, I don’t see how they can evaluate whether or not they are appropriate.

[James’ Reply: So, you weren’t just talking about outcomes, but rather a litmus test about practices based on your own beliefs and preferences. That’s the “best practice” talk that I’m saying is irresponsible. I mean, it’s fine to share your preferences– I do that, too. But when you characterize them as some sort of objective standard of excellence, you have departed from engineering and entered the marketing zone.

No, we must operate under bounded rationality. Many times I have had to evaluate a practice that I haven’t seen and never tried. I’m sure you have, too. Surely you have been in a project meeting where someone suggests a modification to a process, and you think about it, and you say “yeah, let’s try it” or “no way” even though you’ve never done it before. We do the best we can. Sometimes we try things we don’t know much about.]

>> There’s no static formula for success. Stop implying that there is. It’s irresponsible

I never said that. I said that some people are using context as an excuse for never learning or never trying in earnest.

[James’ Reply: When you call a practice “generally good” or “generally bad” in a way that suggests this is more than just your personal feeling or attitude of your particular practice culture, then you are implying there is an immutable universal formula for everyone’s success that requires adherence to that practice. That implication hurts our craft. Please stop.

That some people use the word context as an excuse for bad work is no good reason to criticize the use of the word context, or the concept of context-driven methodology.]

>> >> And not hypothetical ones either. “Full-fledged software developers” who have decided unit testing is the right thing to do, but somehow don’t do it.
>> This is getting a bit far afield from the point of my post, which was a defense against Ron’s sneering attitude about people who follow a different practices than he prefers because of their stated concerns about context.

But that’s my point. Some people use, what I see, as the straw-man of “Agile Authoritarians” to continue to their patterns of too little caring, competence, collaboration, etc.

[James’ Reply: As someone who has had many arguments with Agilists, it’s hardly a straw man, to me. It’s a very real problem. It stems partly from Agilistas who forget (or are too young to know) what it was like when Agile was a new movement, and they had to defend themselves against those who promoted the “generally good” but less agile practices of the 70’s and 80’s.

Because I wish not to simply replace one orthodoxy with another, I have tried to get above the problem by advocating against the idolization of practices.]

>> Oh, and you think the problem is that these people didn’t follow your canned practices?

I’ve worked side-by-side with them for close to two years. I would say that times when I saw them practices being used lead to superior results in the product. And that formally learning XP practices would, in my opinion, help.

[James’ Reply: And you think practices made them superior, independent of the context in which those practices were chosen and applied? I’d like you to look a little deeper. Heck, a lot deeper. I don’t know how many companies I’ve consulted for. Between 100 and 200. And I haven’t yet seen what seemed like a “practice” lead to superior results– independent of the skilled people, acting in good faith, who solved the problems they needed to solve. That’s not to say practices aren’t interesting to talk about. Sure they are. What I’m fighting is the idolization of practice. The Agile community does a lot of idolizing, just as the non-agile communities did and do.

I’m part of a community that does not make monuments to methods. We try to focus instead on the things that matter, like craftsmanship and professionalism.]

>> It sounds like you think of engineering as checking off little boxes, like doing inventory at a grocery store. Or maybe you think it’s like making fries at McDonalds.
>> What a fairy tale you must think software development is. It’s the Brothers Scrumm instead of the Brother’s Grimm.

Why do you need to demonize and belittle me?

[James’ Reply: For the same reason Voltaire made fun of the French clergy– they were behaving as bullies. You say I have “authority” issues. I say I fight bullies. I want the craft to remain free and unbullied, so that responsible people may do good work, and irresponsible people cannot hide behind bad rules. Apparently, you and Ron think people are hiding behind the notion of context. I don’t see that as a problem. It’s trivial to examine, analyze, and debate context-related decisions. I think you guys just don’t want to take the trouble to do it. I think you want people to shut up and do as you say. That’s a bullying attitude.]

>> you claim is due to people having too much freedom

I never said that either. It may make your argument stronger to say that I do. But the reality is that I care deeply about technical excellence and would like to help my team and the development organization (and myself) be better at what we do.

[James’ Reply: You specifically used the word “license” in the phrase “license to make engineering decisions” as if you were complaining about it. Am I mistaken?

I want YOU to drive your project any way you see fit, based on your knowledge, skill, and project charter. I can’t make those decisions for you. That’s not too much freedom. That’s a prerequisite for normal, responsible engineering.]

>> I can’t do that from the pages of a blog, and neither can you or Ron.
>> You can’t supervise from a blog. It doesn’t work that way.

Duh. So this is what I don’t get. On one hand you vigorously defends people’s autonomy, but on the other you don’t trust them take a blog post for what it is. Give people enough credit to filter through a little inflamed rhetoric (blog posts tend to be full of it). To your point, they’re not zombies.

[James’ Reply: I think I know what that blog post was. I think it was bullying. And I’m not giving instructions to zombies, I’m chiding a particular person, in public, for trampling on important principles of engineering because he assumes that anyone who resists his pet practices must be pulling a fast one.]

Even if someone says “suppose to do”, most of us are going to take that as “here are some practices that others have found success with. Learn them, try them out, and see if that helps.”

[James’ Reply: Well, if most of you take it that way, why don’t most of you TALK that way? I’m asking you to be consistent, and not lie to yourselves or each other about the nature of practice. Come on, it’s not so hard. One thing you need to do is respect the role of context. I would also recommend that you get to know the concept of “heuristic” and take it to heart.]

Which leads me to another question. You state in your original post, with what I take as a negative connotation, that:

>> Following is for novices who are under active supervision

Yet, when talking about getting help (specifically some type of training), you state:

>> That can ONLY be responsible in a supervised situation.

Correct me if I’m wrong, but you seem to be suggesting an element of shame around not being able to figure it our on your own.

[James’ Reply: Yes, you are wrong. Where are you getting that? When I learned to fly an airplane, I followed the instructions of my instructor, who was IN THE PLANE WITH ME, and who TOOK RESPONSIBILITY. There is absolutely nothing wrong with that. What you are advocating is that we follow the suggestions of “authorities” who are absent and who take no responsibility (you, by implication, have no “authority issues”, so I assume you believe in doing what you are told by a perceived authority) regardless of whether we feel that something about our context demands that we adopt a different sort of practice. I wish you would stop advocating that. I would respect you more if you stopped.]

I think people should be applauded for being willing to realize that they may not have all the answers. To be open to others who “Preach skill, Give examples. Talk dynamics.” I expect them to think critically, question what they learn, apply it in their context. In fact I’m trusting them to do so.

[James’ Reply: I don’t trust. It’s my experience that few of us automatically overcome the fetishes of practice without actively working at it. You say you expect people to apply practices in context, and yet I’ve heard you say nothing about the challenge and difficulties of doing that. Instead you talk about practices, practices, practices. Do you ever talk about skills? Can you name any skills? Do you know how skills are developed? That’s our challenge, if we want to advance the craft. Stop using TDD as a litmus test for agile greatness. Treat it as your preference, and keep your eyes open for its costs and benefits in relation to other potential practices.]

My concern is that your blog creates an atmosphere that getting training, learning about practices, is for sissies who can’t figure it out for themselves.

[James’ Reply: I’m pretty sure that’s all in your head. I stand for skills and learning and engineering problem-solving. That’s what I do. Most of my work is in training the minds of technical people.]

Every project I’ve ever been on has been a hairball of tradeoff decisions about what to do and not do. There’s no static formula for success. Stop implying that there is. It’s irresponsible.]

And not hypothetical ones either. “Full-fledged software developers” who have decided unit testing is the right thing to do, but somehow don’t do it.

[James’ Reply: This is getting a bit far afield from the point of my post, which was a defense against Ron’s sneering attitude about people who follow a different practices than he prefers because of their stated concerns about context.]

Less that a week to go before release date, being unsure if the product is going to be shippable because of defects. Going in to make a change for a small enhancement and having to spend a day or more cleaning up some unworkable pile of code. And this is after years of the group having “license to make engineering decisions” and being “a” agile.

Or perhaps the “problem” you think you see is no problem at all, but rather a calculated result of trying to create a lot more technology, in a lot shorter time, than the organization can comfortably handle. This may be perfectly acceptable as business risk-taking.]

Sometimes leaving people to figure it out on their own doesn’t work. At some point you have to say “enough is enough” and get some help. Whether it’s Mr Jeffries, or you, or whoever. And then they’re going to have follow somebody’s “pet practices” for awhile.

[James’ Reply: That can ONLY be responsible in a supervised situation. You can’t supervise from a blog. It doesn’t work that way. If someone tries to follow your pet practices, and they fail, what will you say? Will you take responsibility for the failure or will you say “I don’t know what you did, but you musta done it wrong!” I bet the latter. Which is why, if you really believe in responsibility, you need to put a sock in it with the best practice pablum. Preach skill, instead. Give examples. Talk dynamics. But don’t pretend you can diagnose an illness in a project without examining the patient.]

Yes, Ron’s post is rather black and white. But given that for so long many of these “A” Agilists have actual been reluctant to make any dictates, I think it was meant to be provocative.

[James’ Reply: Yes, it provoked me to call him to a higher standard of professionalism.]

A blog post isn’t going to impinge upon anybody’s ability to do whatever they want. Are developers going to spontaneously start doing TDD because of it? Hardly. Might it at least make them think a little more about the quality level of whatever the are doing? We can only hope.

[James’ Reply: I hope no one changes their behavior as thinkers based on devotion to authority. Faith-based engineering is a contradiction in terms.]

[James’ Reply: You want to talk about responsibility, but your examples look like “best practice” fetishism, which strikes me as rather irresponsible. Responsible engineering is not something that is reducible to a checklist of actions. Please talk to me instead about the responsibility we have to speak to each other in ways that honor the complexity and subtlety of the puzzles we are paid to solve.]

In your offense over being told what to do, you’ve given many continued license to interpret agility as “do watcha like”.

[James’ Reply: Nonsense. I am offended by people who oversimplify engineering, and presume to bark orders into a microphone instructing people they don’t know, in projects they don’t understand, to follow pet practices without taking responsibility for the outcome. Only someone with knowledge of and responsibility for the project at hand is in a position to decide what to do to succeed. The rest of us may certainly raise questions from the wings, but we cannot say what should or should not be done, in any definite way.

I insist on license to make engineering decisions on my own behalf and on behalf of my client, consistent with my charter, regardless of what you or Jeffries thinks about it. I believe every full-fledged software developer and tester ought to insist on that, too.]

There’s a big accountability gap in software development. Maybe not where you work, count yourself lucky.

It’s one thing to know that you don’t need to follow certain practices because you have other means to accomplish the same thing. It’s another thing to discredit his message because you don’t like his tone.

[James’ Reply: I attacked his message, Mr. Responsibility-Pants, not because of his tone, but because his message was irresponsible]

http://softwaregreenhouses.com/blog/2009/02/15/dont-let-your-authority-issues-keep-you-from-taking-responsibility/

You seem capable of affirming your responsibility. But how many others will have their emotions fanned by the strong themes in your post around adult/child, supervisor/novice, and skip that step?

[James’ Reply: What would happen if they skip that step? I’m not clear on what problem you are worried about.]

Here’s my reply: http://xndev.blogspot.com/2009/02/context-or-what.html

–matt