Ron Jeffries, one of the capital “A” Agile people, provides a great example of context-imperial talk in his critique of the context-driven approach to methodology:
Well, my dear little children, I’ve got bad news for you. It is your precious context that is holding you back. It is your C-level Exeuctives and high-level managers who can’t delegate real responsibility and authority to their people. It is your product people who are too busy to explain what really needs to be done. It is your facilities people who can’t make a workspace fit to work in. It is your programmers who won’t learn the techniques necessary to succeed. It is your managers and product owners who keep increasing pressure until any focus on quality is driven out of the project.
There is an absolute minimum of practice that must be in place in order for Scrum or XP or any fom of Agile to succeed. There are many other elements of practice that will need to be put in place. And yes, the context will matter … and most commonly, if you really want to be successful, it is the context that has to change.
Wow, he even addresses us as children! That completes the picture nicely. (The context-imperial approach to process generally involves appeals to authority, or a presumption of authority.) This is why I’m proud to be a part of the small “a” agile community, which is not about bowing to priests, but rather each of us developing our own judgment about agility.
Context-imperial methodology means changing problems to fit your favorite solutions. We are all a bit context-imperial (for instance, I prefer not to work in an environment where I’m expected dodge bullets). We are all a bit context-driven, too.
The interesting question is when should we change the problem and when should we try different solutions? For me, the starting point for an answer is skill. To develop skill is to develop both the judgment about context variables and ability to craft solutions for them.
It would help if Ron could explain the dynamics of project, as he sees them. It would help if he offered experience reports. It does NOT help for him to ridicule the notion that competent practitioners ought to evaluate and respond to what’s there and what’s happening on a project.
When Ron says there is an “absolute minimum of practice” that must be in for an agile project to succeed, I want to reply that I believe there is an absolute minimum of practice needed to have a competent opinion about things that are needed– and that in his post he does not achieve that minimum. I think part of that minimum is to understand what words like “practice” and “agile” and “success” can mean (recognizing they are malleable ideas). Part of it is to recognize that people can and have behaved in agile ways without any concept of agile or ability to explain what they do.
My style of development and testing is highly agile. I am agile in that I am prepared to question and rethink anything. I change and develop my methods. I may learn from packaged ideas like Extreme Programming, but I never follow them. Following is for novices who are under active supervision. Instead, I craft methods on a project by project basis, and I encourage other people to do that, as well. I take responsibility for my choices. That’s engineering for adults like us.
Is “context-imperial” the same as “context-aware”?
It’s funny how Ron’s (and Martin Fowler’s) comments echo the same gripes I’ve heard about non-agile methodologies.
So maybe the problem isn’t the methodology, per se, but the fact that teams continually try to force “square projects” in “round methodologies”.
[James’ Reply: Context-imperial is very different from context-aware. Context-aware is a shallow form of context-driven. It’s the willingness to make concessions to context as you do your thing, without making it a central concern. As Cem points out, many people confuse context-driven thinking for context-aware. He explains the diference very well.
Context-imperial, on the other hand, is a hostile attitude toward context. We’re all a little context-imperial, in that there are aspects of context, for each of us, that we may refuse to accept.]
At the moment I very much see a common ground, where Agile (with uppercase) and context-driven people get together: craft. Your blog entry motivates me to keep up on thinking about craft in software testing. What still makes me wonder, is, if those books out there on this topic, still address everything a software testing craftman should know…
[James’ Reply: Yes, exactly. I like the Agile guys when they get excited about craft. I get unexcited when one of them acts as if TDD is the only sane way to code, or as if the ideal size for a subroutine is a single page of code. It’s fine to have a preference. Please distinguish between a preference and a universal truth, guys!]
Although I take your point, I think it would be more persuasive if you simultaneously addressed the problem that Ron is concerned about.
A lot of people point at things in their context as excuses for continuing to dodge the reality of their situation, and to avoid the hard work of actually fixing what ails them. I encounter this regularly as a coach, and for me one of the biggest success indicators for an agile adoption is being able to overcome that.
From your critique of Ron’s use of ridicule, you seem to believe that there’s a better way to do things. But saying “X is bad” without following it up with “… instead, do Y” isn’t very helpful. You can increase your credibility further by pointing to examples of you actually doing Y.
[James’ Reply: Actually, I did say what to do. Read it. It’s right there: focus on skills and problem-solving. My whole professional existence is dedicated to that approach, and that does deal with the problem Ron cites.
I also see people use “context” as an excuse. I simply address the issue specifically, as a problem to be solved. Context factors won’t allow you to use solution X? Okay, what is it about the context that creates that obstacle? What can we do to overcome it? What alternatives are there?
When objections are raised to my favorite ways of working, the LAST thing I want to do is complain about people who raise objections. Instead, I need to deal with each specific objection. Our field needs thinkers, not to be dissuaded by graybeards from questioning authority!
The invocation of context is not itself a problem, as I see it. However, the pushing of “process” by means of authority rather than through the logic of technical persuasion IS a problem, unless you are pushing that process to people who work for you.]
I prefer to think of my preferences for particular work environments as being context-selective rather than context-imperial. That is, I want to work in places that maximise my chance of success. If other people want to do things differently, that’s fine. I’ll just not necessarily work there. If I’m trying to change things, it’s hopefully to improve an outcome, not to push things toward what’s comfortable for me.
I step outside of my comfort zones when my rate of learning begins to slow.
[James’ Reply: Context-selective has a nice ring to it, and that’s a different attitude than imperious.]
Hello again, James.
I agree that our field needs thinkers, who coolly and rationally consider all problems, solving them smoothly. However, what we have is a bunch of dressed-up, half-evolved monkeys, you and me included. When the problem is that people don’t understand the solution, I’m all for a thoughtful discussion over tea. But if the problem is that people avoid understanding, or understand but avoid acting, other methods are called for.
[James’ Reply: I’m not specifying what methods must be used. I’m defending the idea– and I’m a little embarrassed for our community that I should have to defend it– that the competent practitioner does not merely push for what he wants to do, regardless of the circumstances. The competent practitioner is able to assess the context, honor the context, and craft a reaction that responds to that context.]
For example, for years I knew I should exercise. But until I eventually hired somebody to push me to exercise, i never did as much as necessary. It took me a few years of that before I could do it sufficiently on my own. The solutions to my problems lay in the realm of experience, not in the realm of discussion and consideration.
[James’ Reply: How does this invalidate context-driven methodology?]
As part of our monkey heritage, humans are hardwired for all sorts of authority-related behaviors. From a coaching perspective, that can be pretty handy. It’s true that you can use authority in a way that reduces people’s willingness to think and increases their deference to authority. But you can also use authority to force them into situations where thinking for themselves is more effective and more rewarding. You can use authority to decrease the power of authority.
To me, that seems like what Ron is doing here. He’s using his authority to tell people to take authority. I understand you personally don’t like being told what to do. In which case: fine, this message isn’t for you. But for those who are prone to excess deference to authority, an authoritative kick in the pants may be just what they need to get moving. When that works out, they get the experiences they need to get over that deference.
[James’ Reply: I find that a deeply irresponsible attitude. Unless Ron is in a position to take responsibility for other people’s work, he should not presume to use authority to push them into anything. It’s unethical, full stop. It’s like a doctor who prescribes medicine for a patient he’s never seen and knows nothing about. If our craft was serious enough to have established a standard of malpractice, that would certainly qualify as malpractice.
And what about local thinkers, in an organization that is following an absentee consultant? I have been in the frustrating position of trying to argue with people who did not arrive at their position through any reasoning of their own, but rather through reading some book or hearing some favored guru. It’s hard to argue with someone who is not present in the conversation.
I want to call us, as a field, to a higher and better behavior– taking responsibility for our choices and learning to explain and defend them without appeal to authority.]
While I somewhat agree with both of you, I hear you both talking nearly at cross-purposes.
Jeffries cites issues that are clearly problems: managers unwilling to release responsibility, salespeople who are too busy (in my experience, too inarticulate) to explain to manufacturing what customers will buy; facilities people who maintain a bad work environment; programmers who resist change. These are all problems that will plague any approach, but It is certainly not clear how they support Jeffries’ argument.
[James’ Reply: They may be problems. Whether or not they are problems they are elements of the context. Changing them is one way of dealing with them. Changing our approach to development is another way. We development people sound like whiners when we only talk about changing other people rather than looking at ourselves.]
These issues are going to be a problem no matter what approach you take. (I know that’s a huge surprise to everyone.) Saying that this has to change is about as futile a thing to do as I can think of. It brings no help, no enlightenment and no procedural suggestions or improvements to the situation.
[James’ Reply: I don’t agree that these issues are necessarily problems. Projects have succeeded even in such a context. What Ron seems to be saying is that it’s never correct to do something other than his pet methodology when the context doesn’t support it. Instead, he seems to be saying that the project can’t succeed until that context changes. My reaction to that is, “bullshit!” Maybe Ron doesn’t want to operate in such a context, but that’s a different matter.]
If there were a good way, or even a partially effective way, to change these matters, then we’d do that. Sometimes we actually have done. Edwards Deming could to it to Ford Motor because they saw the handwriting on the wall if they didn’t. (Funny how quickly they lost sight of it again, no?) But the rest of us are pretty much stuck with the people, and the management, that we’ve got, and we’re not Edwards Deming. We can’t demand that everybody including the directors buy into our program in writing. What we need are ways to be effective in spite of these issues; to cope rather than to complain, denounce and pontificate.
Everyone, practically everywhere, faces these things. If Agile (or agile) won’t work unless they change, then great, Agile won’t work. Maybe it’s not fair to blame you for that, but you’re the one who is going to be laid off or fired for being ineffective.
In a certain sense, though, it’s entirely fair. If all you’ve done is to impose a set of practices that won’t work in the existing environment; and then complain about the environment instead of adapting to it or switching to practices that DO work in this environment, you aren’t contributing anything. (Now go back through that sentence and mentally substitute “context” wherever you see “environment”.)
Dismissing it all with, “if you want to be successful, it is [these things] that have to change”, just doesn’t help. Neither do generalizations like “then you have to change the problem”.
[James’ Reply: I do thinks it’s fair for someone to say “I don’t know how to succeed in any context but the following…” Perhaps Ron doesn’t know how to make agile work when managers won’t delegate responsibility. That’s fine. But to imply that the rest of us are silly for even trying to adapt to the reality on the ground? Please.]
What I need from Ye Exalted Leaders In The Craft is a set of practical solutions for these issues, viz, “here’s what you do when you’ve got a clique of coders who simply refuse to change their practicum, a manager right in the middle of the project who just will not relinquish any authority for anything.”
I DON’T need to hear “tst, tsk, they need to change.” There isn’t a lot of light on this issue coming from any side here.
But on the other hand, I can’t quite agree with your position on never following. As an example, take the XP concept of pair-programming. I think this is one to follow, even slavishly, and can’t conceive of a situation where PP would NOT produce better results even when done in the most half-assed manner. Well, I could certainly be wrong and perhaps it’s just a failure of my imagination.
[James’ Reply: I suspect that is a failure of your imagination. For instance, perhaps you have failed to imagine a situation where I have 10 minutes to code up a throwaway data generator for a test I want to do. You think I should wait to find another programmer to work with before I dare to put fingers to keys? I don’t believe that you would. Or perhaps you aren’t thinking of a company that employs only one programmer.
Remember that “better” is a human idea, not a universal truth. Maybe you feel strongly about PP. Personally, I’ve experienced it, and I like it, but it’s not the only thing I like.
Regardless, if you always prefer a certain way of doing things, that’s not necessarily following. To follow is to submit to the technical judgment of another agent, in work that is your responsibility, instead of using your own judgment. I recommend against following, generally speaking. It is not engineering to impersonate a zombie. You can pay attention to the ideas of others, and even apply them, without merely following them.]
I also can’t quite go with the “project by project” basis. Maybe OK if you are a consultant, but maybe not if you’re a permanent member of the team and will be working on other projects with many of these same people. Longer-term solutions are required then, or so it seems to me.
[James’ Reply: You mean you don’t allow experiments? When I was a day to day test manager, we changed our process frequently, even during a project. Certainly from one to the next.]
Then too, we can aspire to effect permanent change in people, or at least leave them thinking, “gee, that was better that what we usually do.” This needs a further horizon that just getting this project out the door and our solutions ought to be viral by their nature.
[James’ Reply: You know what else is viral? DEADLY VIRUSES. Maybe before we set a new solution free in the wild, we ought to consider how it may not work for everyone or everything. Maybe we ought to gain experience with it.]
Hiya James / All,
Ron’s posts make good reading most of the time (agree with him or not) but this one is so far removed from the day to reality of most test practitioners.
For most test practitioners the idea that they can somehow acquire the authority and have the time to make business level change is a fantasy. Most of us are wrapped up at the day to day project level, full time in being participants within teams and organisations that require our focus of effort to just be convinced of our value. Stepping ahead of that to the point where we’re negotiating change of desk layout, PM practices, etc. would get you kicked from the team.
As a manager where you should be operating at the business level you’d at least have a chance of raising your concerns. But I’d suggest the reality here is you’re only going to see change on longer term projects or where agile is established and that business level change makes sense.
No one would argue you should engage in projects or set teams up in a way that supports high-bandwidth comunication, facilitate interaction, etc. But with most of my projects being 8 to 12 weeks I have to make the best of what’s there most of the time and ‘petition’ for the other business level changes. Usually there’s no time, as a consultant the client is off and running and I’m brought in to play a role, not run the project.
That means what then? That means I have to employ contextually correct testing practices and approaches of course. What else are you going to do where you’re on the ground having to test? Fight the business, project, processes and insist it’s my way or the highway? Great for folks like Ron I guess but the common or garden test consultant is going to be updating thier CV.
>I don’t agree that these issues are necessarily problems. Projects have
>succeeded even in such a context.
These aren’t equivalent. I didn’t say the project could not succeed, I said they were problems, and I do indeed think they are. One must at minimum work around their effects and hope that they are minimal. But to think that they won’t be problems seems the height of foolish optimism to me. I would certainly never go into a situation expecting so or failing to plan for the opposite.
[James’ Reply: I didn’t say they won’t be problems. I said they won’t necessarily be problems. I’m not making a prediction or prescription, I’m simply advocating for situational analysis.]
>What Ron seems to be saying is that it’s never correct to do something >other than his pet methodology when the context doesn’t support it. >Instead, he seems to be saying that the project can’t succeed until that >context changes. My reaction to that is, “bullshit!” Maybe Ron doesn’t want >to operate in such a context, but that’s a different matter.]
Your understanding would be that he therefore advocates doing nothing in that situation.
[James’ Reply: No, that’s not what I said. Nor is it what he said.]
If you take a step backwards, have a deep breath, and a little detachment, I think you’ll agree that this doesn’t compute. If the understanding is that he advocates just doing nothing, then the understanding is faulty. We need to try again. We need to refactor our understanding of what’s being said.
[James’ Reply: Yes, it doesn’t compute. But that’s not what I said.]
I perceive that the issue he’s addressing is, “Agile didn’t work for us. We tried it and it didn’t work.” His answer is, “if you want it to work in your organization, then these contextual or environmental things just have to change. If they “cannot” be changed, then no, Agile won’t work for you. Scrums won’t work for you. Nothing will.” (I’m not saying that I personally buy into all of that, merely that this is what I take him to have said. His conclusion is not “do nothing”, it’s “Agile isn’t going to work for your organization if you won’t change.”
[James’ Reply: I know, David. That was the very point I was taking issue with. I am disagreeing with Ron that agile can’t work under those circumstances. I mean to suggest that his attitude is unhelpful. I mean to suggest that context-driven modifications of one’s methods is important professional behavior.]
I don’t hear him talking about specific projects. To the contrary, I hear him talking about the whole organizational effort to implement a quality program, and indeed mocking the pseudo-efforts of some of them in this direction. Here, I empathize: I’ve had bosses who would pretend to listen and even advocate a team quality approach right up to the point where they personally had to relinquish any of their tightly-held authority, but then it all went out the window.
[James’ Reply: Yes that can happen. Just because that happens, however, does not mean agile can’t work.]
I hear Jeffries calling out organizations who won’t adapt to Agile on the grounds that” it doesn’t fit their context”, and crying bullshit on that. This is very familiar territory to me – lip service given to the quality effort, along with a determination to avoid any actual change.
[James’ Reply: Well, I’m defending those organizations, and defending the notion of context-driven methodology. Ron would not criticize mathematics based on some people misusing math, would he? He should also not imply that context-sensitivity is always some sort of cop-out.]
I don’t read an attack on context except as it’s used as an excuse to skip the hard parts of instituting an effective quality program.
[James’ Reply: We understand his words differently, I guess.]
What you do about that situation though, well, if you’re a heavyweight consultant, you presumably have one set of options, but as Mark observes just above, they won’t work too well for most of us.
>I suspect that is a failure of your imagination. For instance, perhaps you >have failed to imagine a situation where I have 10 minutes to code up a >throwaway data generator for a test I want to do. You think I should wait to >find another programmer to work with before I dare to put fingers to keys? I >don’t believe that you would. Or perhaps you aren’t thinking of a company >that employs only one programmer.
Of course not. It isn’t Levitical, it never was. If it’s completely impractical or you just can’t, then you don’t do it, but that doesn’t mean you don’t recognize that you ought to anymore, or that the code isn’t highly suspect just because you couldn’t write it in a pair.
[James’ Reply: I don’t find it helpful to think in terms of rules, generally speaking. I don’t follow or believe in best practices. I think in terms of heuristics and dynamics. In other words, I don’t see why I should say to myself “paired programming is usually best.” I simply say “what is a reasonable way to solve this problem, here and now?” Then I design such a solution.]
In that case you recognize that the code you’re about to produce by yourself is extremely likely to bite you in the ass from defects in it someday — that there’s a higher risk of this, and that you need to be aware of, and deal intelligently with that risk. ( Jeez, James, I learned that technique from YOU.)
[James’ Reply: I’ve been programming a long time. I haven’t been bit very much. But then, most of my code is not part of a mass-distributed product. In any case, I can manage my risks without pre-judging my methods.]
—
(This is just throwaway code. This is just a temporary tax. Yeah.)
Hello James. It looks like you had a similar reaction to Ron’s post as I did, we just … channeled it differently.
Here’s my reply: http://xndev.blogspot.com/2009/02/context-or-what.html
–matt
Your response to Ron’s article inspired me to write my own post, centered around misunderstanding the message as one of authority, versus responsibility:
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.]
Fantastic post. I think your emphasis on thinking professionals vs. unthinking zombies hits the mark. Software development really is a type of intellectual pursuit.
What happens when they skip the step of responsibility? Developers talk about agility, but rarely write unit tests. Hundreds, if not thousands, of “acceptable” defects come release time. Two days to make a change that should have taken two hours because of cut and paste code.
[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]
I gave you outcomes, not “best practices”.
[James’ Reply: No you didn’t. Read your own words. You cited “unit testing” as good and “cut and paste code” as bad. Those are practices. Do you think by citing a problem with “cutting and pasting code” you demonstrate that it is a universally bad practice? Do you think that the absence of unit tests is always bad thing, apart of any context or justification?
Do you think that most problems in software projects have simple root causes such as “didn’t follow practice X?” I think engineering is a little more complex than that.
If there are thousands of problems called “acceptable” in code, is that a bad thing? Maybe. Maybe not. I’ve been in the software business too long and seen too many different kinds of problems to accept your point.
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.
[James’ Reply: Oh, and you think the problem is that these people didn’t follow your canned practices? Really? It doesn’t occur to you that there could be another explanation? 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.
I would look at the same situation you claim is due to people having too much freedom and come to a different conclusion. It could be any of:
1. not “too much freedom” but too little caring.
2. not “too much freedom” but too little competence.
3. not “too much freedom” but too little collaboration.
4. not “too much freedom” but too little support from management.
5. not “too much freedom” but too little supervision by leaders who are competent and caring and collaborative. In other words, if I think someone really has too much freedom, the solution is not to reduce freedom in ANY OLD WAY, the solution will have to be give that person effective guidance. I can’t do that from the pages of a blog, and neither can you or Ron.
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.]
>> Do you think by citing a problem with “cutting and pasting code” you demonstrate that it is a universally bad practice?
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.
Your logic for evaluation is interesting. By that logic, no one can competently settle on ANY practice, because to do so, they must evaluate the alternatives, and there are an infinite variety of alternatives, most of which have not been tried.
Furthermore, practices are always situated. A practice that failed when you did it might work fine for me, because I tried harder, or because I different skills and habits, or problems, or clients. So even with experience, my evaluation and yours may differ.
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?
Here’s what the word “license” means:
1. formal permission from a governmental or other constituted authority to do something, as to carry on some business or profession.
2. a certificate, tag, plate, etc., giving proof of such permission; official permit: a driver’s license.
3. permission to do or not to do something.
4. intentional deviation from rule, convention, or fact, as for the sake of literary or artistic effect: poetic license.
5. exceptional freedom allowed in a special situation.
6. excessive or undue freedom or liberty.
7. licentiousness.
8. the legal right to use a patent owned by another.
–verb (used with object)
9. to grant authoritative permission or license to.
So, do you see how I thought you were talking about “too much freedom” being a problem?
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.]
Clearly the question of whether a professional’s day to day activities need to be guided by some kind of religious dogma needs to be answered on a case by case basis. I don’t see how anyone could make a blanket statement about that dogma being good or bad all the time. There will be times, and individuals, who will benefit, others may not.
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.]
[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.]
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.
There are many cases where following a particular practice is important simply because everyone else does. We call those social conventions. For instance, we drive on the right side of the road in the U.S., but if I drive in England, I follow a different convention.
As I sit here I am not able to think of any conventions that apply to the entire testing field.
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.]
[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?]
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 do have access to what folks say about themselves and their experiences. “What worked for someone else” is really a story that they tell about what worked for them. The story may be useful, but as any social researcher learns in the cradle of their career, you cannot take any such story at face value.
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.]
Interesting point… I had second thoughts about my response to your innovation comment as I was afraid it would be an unhelpful distraction as it turned out to be.
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.]