Where does an author or speaker’s responsibility to be clear stop and the audience’s responsibility to comprehend begin?
A number of years ago an official in Washington DC used the term “niggardly” in a sentence. He was chastised, not because he had used a racial epithet but because he should have known some of the people who heard him might have thought it was a racial epithet.
While not as extreme as this example, I received a very angry e-mail from a long-time subscriber because of last week’s column.
What I said was that if we’re going to retire the term “SOA” because it has become associated with big, bloated projects then we should subject the word “methodology,” which is even more guilty of the same corporate felony, to the same treatment.
We should also ban the word because it’s usually used where methods would be more appropriate. Methodology should mean the study of methods, not the methods themselves. But that ship has long since sailed and I’ve given up.
Back to the complaint. The issue wasn’t what I’d said, he explained, but that CIOs and other busy executives might misunderstand it and ban the use of organized methods for developing software, resulting in utter chaos.
I only wish I had that level of influence.
Just in case my point wasn’t clear last week, the methodologies themselves aren’t the problem, unless you’re using waterfall methodologies, at which point they probably are (see for example “Global sourcing countertrends,” 5/3/2004).
No, the problem doesn’t lie in the methodologies themselves. It lies in their cooption by those who turn them into religions, complete with orthodoxies, splinter groups, apostasies, and all the other distractions religiosity introduces to prevent potentially productive employees from accomplishing something useful.
The symptoms are easy to spot. If project team members brandish methodology treatises as weapons, arguing about which author has a better handle on the situation or about what a particular author meant, you have a problem. Discussions (not arguments, which are about winning and losing, but discussions, which are collaborations) must be about what will best fit each situation.
Imagine some poor impressionable executive read my column last week, did misunderstand it, and did issue a methodology ban. Would the result be chaos?
Probably not. The alternative to methodology isn’t chaos. The alternative is invention — not the best solution when a lot of good thinking has already been published on the subject, but not a disastrous outcome either.
Chapter 8 of Keep the Joint Running: A Manifesto for 21st Century Information Technology includes a discussion of process, practice, invention, and how they differ:
Process is what assembly lines do. They establish a fixed sequence of steps which, if correctly followed, guarantee repeatable, predictable results.
When you need repeatable, predictable results, which is to say when you’re going to do the same thing over and over again and need results that adhere closely to specifications, a process is just the ticket.
When developing software, or when designing business change even more, adherence to specifications isn’t the goal. It can’t be, because each set of specifications is used only once, is open to interpretation besides, and usually turns out to be the result of incomplete thinking … inevitable because by definition the project team hasn’t built this piece of software before or made the business run in the intended new way before.
That’s what’s wrong with too many methodologists (a good reason for not retiring “methodology,” by the way: If we switched to “methods,” we’d have to call practitioners “Methodists”). They try to turn methodologies into processes, when in fact they should be defining them as practices.
In a practice you also define the steps required to get results. Unlike a process, practitioners have a lot of leeway in how they execute each step — most of the specifics are a matter of judgment.
Also unlike a process, in a practice repeatable, predictable results isn’t the point. A successful outcome is the point, whether it means beating a competitor, getting a client off the hook, curing a patient, or producing software business colleagues use productively to operate in a new and better way.
Bowling is a process. Hitting a baseball is a practice. If you throw a bowling ball exactly the same way every time on the same alley, you’ll knock down the same number of pins every time. If, in contrast, you swing a baseball bat the same way every time you’ll strike out every time, because the pitcher will throw the ball where your bat isn’t.
Every time.
About your level of influence
“I only wish I had that level of influence.”
My experience is that only when you don’t want the influence will you actually have some 😉
Great column!
Translation: Once again I agree with practically everything you said.
I can’t believe you used the “niggardly” example. I use that often myself. I guess we are all patterns after all.
-DC
OK… now you have been elected to my geek Pulitzer. Why?
Because you have illuminated, in a single, simple paragraph, why I had a vague misapprehension about the much bandied about buzz-phrase “repeatable process”. It’s simply this – patterns exist, but in my experience we never have repaeating requests. If we do, we didn’t provide a good solution to the original request. So why repeat our mistake?
Sure, patterns are constantly repeating themselves. But place too much much emphasis on the “repeatable” part of process, and you are just fooling yourself. We rarely seem to have truly repeating requests, and when we do we typically no longer have to worry about repeatable process, because we’ve fully automated solutions to those last year.
You realize, of course, that you’ve opened yourself up to another round of nasty emails by those who think you’ve denigrated religions, right?
Good column, excellent illustrations. BUT, you did not complete your discussion of Methods. Methods are the algorithms of reusable objects, which I am sure you know. One of the most successful methodologies is to program using object-oriented languages because of the reusability of objects, which I am sure you know. Most methods are not new, but only the application of those methods. So we should pay attention to methods WHEN we are talking about software development and objects. Use of such objects often removes the errors of spontaneous invention.
You knew this had to happen… batting is a practice only because the delivery of the ball is a variable. Over the course of the game the batter must adjust for this variable. In bowling, assuming the bowler can release the ball exactly the same way each time, over the course of the game varialbes like the temperature of the ball, the amount of oil it has absorbed from the lane, the amount of oil left on the lane, and dozens if not hundreds of other variables will result in the ball not tracking the same each time. The bowler must adjust for these variables just as the batter must adjust for the variables of the pitch.
If the difference between process and practice is adjusting for variables that are out of your control then pretty much any sport will fall into the “practice” category.
A good column, but I’ve gotten a bit lost on the difference between a process and a practice. I’ve always though of a practice as a unit of action (a step in a set of steps) and a process as a set of steps. Since the size of a step is context specific, it isn’t wrong to say “we implemented a practice of process improvement.” It does bend the brain a little because of the distinct unstated subjects, but it just means that we added a step to our normal work to review and update the way we do work.
As a fairly decent scratch bowler, I wanted to note that you probably need to hold your conditions on the lane in the bowling alley a little more constant for your analogy to hold. First of all the oil on the lane moves, making the ball turn in different spots. As you bowl the temperature of your ball rises making it stickier, but it absorbs oil, making it more slippery, and then you have to wipe it off, making it stickier. Humidity and room temperature affect the travel of the ball as well. Then of course, there are your shoes, you yourself get tired (or you drink too much beer). I don’t remember anyone ever telling me how I “had to execute my bowling process” (in fact I have several different approaches for different conditions). Perhaps you would do better to compare baseball to golf, where hitting the ball the same way every time on the same hole will yield constant results? Just kidding!
The underlying point, though, seems to be whether or not you are facing an “antogonistic intelligence”. You appear to be saying that “process” deals with unintelligent reality and “practice” deals with intelligent opposition. I’m not quite sure this is a valid operational definition.
I do know that practice did make my bowling better though. It doesn’t seem to help my golfing ability as much.
Cheers,
Andrew
A student of rhetoric might object to your statement ” arguments … are about winning and losing, but discussions … are collaborations.”
In the context of formal rhetoric, an argument is a collaborative discussion in which the participants also are attempting to persuade.
I typically do not like sports analogies for business however applicable they may be, but that bowling/baseball comparison is memorable.Thanks.
Pingback: A modest proposal | IS Survivor Publishing