Everyone Should Bea Methodologist
Everyone Should Bea MethodologistMichaelJackson said page 115 of Software Requirements & Specifications -- Instead of being just a user of one method, you must become a METHODOLOGIST. I rather think though that that is just a turn on the same idea that got us here -- i.e. no method doesn't work, and all methods are flawed, so learning many methods helps you pick the one that applies, capish? --RaySchneider''
That's exactly the one I was thinking of when I started this page--KeithBraithwaite
That makes the title of the page make more sense to me. Maybe its just the word Methodologist that gives me the shivers. What we want to be is not someone who studies method but someone who applies it. What about a different spin: EveryoneShouldBeaDeveloper? -- BillBarnett
These days I don't believe in methods at all. The client I'm working with at the moment is very much in love with EntityRelationshipModeling, and we have had to devise ways to accommodate them without breaking our oo/components approach. After going through that mill I concluded (and said to the client), that I no longer believe in methods (XP included), I believe in techniques, from which the software professional must choose those appropriate to the task in hand.
Now, I'm sure that seems like a truism to most people of Wiki, but I've been interested to see this progression within myself.
If no methods work, maybe its the way he/we/you think about methods that's flawed. Try starting from there. --AlistairCockburn
It might be interesting to know who else has followed a path similar to this, and more interesting to know who hasn't...
I was first told that techniques were the most important things. A couple of years later I decided that techniques are personal, and standards are the most important things. A couple of years later I decided that team structure is the most important things. A couple of years ago I decided that techniques - but not big technique; microtechniques are the most important thing. I'm waiting to see if I go around this circle again. (Fortunately, I've never been told, by anyone I trust, that process is the most important thing.) --AlistairCockburn
I agree with the sentiment of this post, but the title makes me cringe! NoOneShouldBeaMethodologist? seems more appropriate. My observation over time is that all too often methodology turns into methodosophy. That is why we refer to XP as a development approach -- which, I suppose, implies that it is a collection of practices rather than a formal methodology. -- BillBarnett
(also, I just read this today, and can't help passing it on:
"When we are caught in the notions, rituals, and the outer forms of the practice, not only can we not receive and embody the spirit of our tradition, we become an obstacle for the true values of the tradition to be transmitted. We lose sight of the true needs and actual suffering of people, and the teaching and practice, which were intended to relive suffering, now cause suffering." -- ThichNhatHanh, in LivingBuddhaLivingChrist?, Riverhead Books, 1995, ISBN 1-57322-018-3 )
That's far too true.
all too often methodology turns into methodosophy
I like that a great deal! I will make a note of the word "methodosophy", and use it more often in every-day conversation. Gobbledegook.
Two points:
Maybe we could avoid the danger of methodosophy if we emphasize the notion that for each project (they all varying in some way or another), the set of available techniques needs to be re-appraised and a subset chosen for the current situation.
I think the question is whether the rituals prescribed by the chosen methodology remain means to delivering working software, or become ends in themselves. I frequently use AlistairCockburn's ValidationV model to describe the fact that the only real validation of any activity associated with software development is the feedback from real users using the real system. As software development professionals (and ordained methodologists) we like to think that there is real validation (read: meaning) in the act of producing a detailed requirements document and the rituals associated with the act of our customer signing it.
I seem to be on a FarEastQuote binge today <g>, but I remember a very good passage from Musashi's BookOfFiveRings where he commands the student of swordplay to always remember that his goal is to kill his enemy. He is not learning to parry, thrust, spin, whatever. He is not practicing a high block or a low feint. He is trying to kill his enemy. All the individual practices are means to that end.
''But, in the same book, he defends nito-ryu (two sword guard) pretty vehemently. He actually slams other schools. He is also pretty rigid in other technical aspects (how to move, what to scream...). Mind you, the book is extremely interesting when he speaks of goals and mindsets. -- JeanPhilippeBelanger''
I also remember JerryWeinberg in QualitySoftwareManagement saying that it is important for us to develop models that we can act as if we believe in. But that if we actually start believing them, we are in trouble. -- bb
One meaning that getting a document signed carries is defending yourself against penalty clauses, but that's another story
As you can tell, I am nowhere near an objective observer on this topic. Please interpret my comments based on my limited experience. I have spent my career (so far!) in a single large corporation. I have watched many totally ineffective bureaucratic attempts to impose big-M methodology on project teams, using both data-centric and object-centric approaches. I have never seen a project team point to the methodology and say "Boy, we could never have been successful without __________!"
but I bet you could say that of one or more techniques
It seems that our development teams usually either get so focused on the methodology that they can't do anything else, or respond violently in the other direction and decide they will do the whole project by the seat of their pants. Often these two approaches are adopted sequentially. Neither approach makes for good software (or happy developers).
But maybe what was wrong was not the methodologies themselves, but how they were applied to the projects at hand?
That is why I am so enthusiastic about XP (at least, about the XP practices we've adopted <g>). Because we DO point to it and say we couldn't have been successful without it.
I would not recommend that anyone decide that methodology is an unrecoverable term based on my emotional reaction to it. Think of me as allergic. <g> The question is: how many others out there share this allergy? -- bb
the only real validation of any activity associated with software development is the feedback from real users using the real system
I'd like to believe that I believe that, and behave accordingly most of the time. Maybe I'm lucky in that I've often worked with people that seem to.
One thing that did strike me during the period when I was working with Syntropy was that we produced a lot of very deep documents, that, in retrospect, have no utility as deliverables, but: the process of writing them made us do a lot of thinking that we might not otherwise have done. --KB
I definitely connect with that experience. We frequently find that the design process is invaluable, but the documentation at the end is almost (not quite) superfluous. See TheSourceCodeIsTheDesign.
The question is: How do you maximize the value of the process while minimizing the cost? And is there a way to do JustInTimeRequirements? and JustInTimeDesign? At first, you need to understand the high level requirements well enough to decide on an architecture, agree on customer priorities, and estimate overall effort and scope the development interval (create the WorkQueue). You can then develop the detailed requirements (UseCases or UserStories) to flesh out each "row" on the WorkQueue 'just in time': as you implement the function. -- bb
The question has a ManagerAssumption? it it that just isn't true. Since cost and value depend upon one another, you can't maximum one and minimize the other.
Sure you can. Isn't that just the kind of min-max manufacturing problem you can use linear algebra to solve? For software development it might be harder to quantify, but the concept is the same. In fact, a pretty common economic goal is to optimally allocate resources so that you get maximum output for minimum cost. Did I misunderstand your point? -- bb
The (un-PC?) concept you're groping for is maximum profit (value minus cost). The math would be conceptually clear if we could define the cost and revenue functions. But this variable "how much methodology" is a bit hard to quantify and there are too many other interacting variables. Seat of the pants looks pretty reasonable. DaveBurns
Cutter Consortium has some sort of a weekly e-zine and monthly paper version, editied by JimHighsmith, another ultralight project manager type. Someone sent me an excerpt from a recent article, which belongs on this page. Visiting their site, I found the link at http://www.cutter.com/consortium/index_articles.html to be a bit obscure. They want one to subscribe, so I couldn't find the article I wanted in the short time I was there.
But (slowly getting to the point), JimHighsmith has an article in the Dec '99 issue about "just-enough" requirements, and in Feb'00 about XP. He quotes me, so obviously he has good sources ;-). More interestingly, he summarizes multiple people's views on this page's topics that make good sense. If someone can decode the URL for the two articles, they'd be good to post here and on WhosWritingAboutXp. --AlistairCockburn
Talking of Cutter, "When Good Enough Is Best" was a helpful article along similar lines by EdYourdon in the September 96 Byte - just as NickSimons and I were writing the SevenPillarsOfCred for Ed. Our JustEnoughDesign pillar was partly borrowed from this article.
Ed also introduced "triage" to the discussion of method in the same article. Nick and I immediately felt: here's a term that almost everyone could use with benefit in a software development context (does anyone else out there have project experiences that seem to need BattlefieldTraumaAnalogies?).
The punchline, as ever, came from Nick, who looked up the word in Chambers Dictionary and emailed me with delight the following definitions (remembering that our focus at that time was a lightweight method for Java):
Relevant assertion from ProgrammersStone: "The point that languages are real, and approaches are real, but methodologies are a figment of our collective imaginations and do not exist must be emphasised." -- BillBarnett
Well, methodologies are exactly as unreal as cultures. In fact, cultures are a figment of our collective imaginations... and that's what makes them real. Ditto methodologies. (A culture is rather like a loaded bear trap waiting to spring. Murmuring mantras "it is not real" and whistling optimistic tunes won't help when it goes 'snap' with you inside.)
Actually, I have worked places where they think cultures aren't real. Working there was about as much fun as you might imagine (working in a loaded bear trap comes to mind). --AlistairCockburn
So, is this the methodology equivalent of "yes, virginia..."?
I understand your point, Alistair. And one of the frustrating things about reading the ProgrammersStone (so far, anyway -- AportisDoc? tells me I'm only 37% of the way through) is that it seems to assert lots of interesting (or at least provocative) things without clearly explaining the argument that supports the assertions.
I have a fuzzy sense of what they mean. Languages are tools, approaches are specific activities and artifacts, but methodologies are abstract mental constructs that bind tools, approaches, and maybe other things together.
In the next few sentences they seem to shed some light -- albeit still out of focus, IMO -- on the sense of the assertion, and it echoes much of what's been argued more clearly <g> here. Since methodologies are mental constructs only, it is important to make sure the one you are applying to your project corresponds with the details of that project (which, according to the PS guys means primarily tools and business domain). If not, there will be tasks and approaches that are appropriate -- maybe even crucial -- to the team's success that are essentially verboten because they're not mentioned in the methodology. And people on the team who try and raise how important they are to this specific instance are labelled 'unprofessional' for not 'applying the methodology.'
This also seems to tie back to the JerryWeinberg quote mentioned above about acting as though we believe in the models, not actually believing in them. -- bb
Two little quotes. RalphHodgson taught me the phrase, " Methodology is a social construction. " My own curent phrase is, " Methodology is culture design. " Practitioners of XP should be able to affirm to these two sentences. --Alistair
It's great to hear of Ralph again. One of my favorites of his was at the end of a GoldfishBowl discussion probably organised by BruceAnderson on some aspect of objects at the British Computer Society in the 80s. Everyone was given the chance to say how they though it had gone. Ralph said "I'm not sure what I learnt about object-oriented design but it was great object-oriented therapy" which summed up the cultural benefits that day pretty well.
My own taste would be to say that method and culture are separate and that culture is much, much more important. But that's because I want to make method as small as possible.
As for the quote at the top (having been refactored mercilessly by Keith up there) I felt when I first read it that it's Michael at his most impractical. Most developers haven't even read one book on method, let alone many (which is what would be required by the "-ologist" suffix used by Jackson ... a studier of method). But at least Michael means something altogether more rigorous and indeed smaller by method than the normal bloated ambiguous-ware. Such as JSP - still his favorite baby.
rituals prescribed ... ordained methodologists ... rituals associated ... act as if we believe ... bloated ambiguous-ware
Ouch! If "methodology" really carries all that negative affect (if I'm reading you correctly), then I suppose the word is useless now.
Not in my book. The word methodologist needs to be rebuilt almost from scratch though. Someone who goes around projects and measures what they actually do against what they say they do is the very start of this rebuilding process for me. Arise Sir Alistair! --rd
It seems that our development teams usually either get so focused on the methodology that they can't do anything else, or respond violently in the other direction and decide they will do the whole project by the seat of their pants. Often these two approaches are adopted sequentially. Neither approach makes for good software (or happy developers).
Well said. These "devil and deep blue sea" and "false alternative" points have been expressed elsewhere on Wiki but they represent the reality of development activity on the ground so much in my experience that I don't we've talked about them anything like enough or forcefully enough.
So, just to provoke thought ... let me propose the following:
1. Method is only as important as the percentage of software developments really trying to use one. This is very small so method has in fact been very unimportant.
2. The majority of projects have been right to use 'seat of pants' until XP came along (as long as you ignore TomGilb).
--rd
It has seemed, from time to time, that the eXtremists have been attempting to manufacture a ParadigmShift where, in fact, no paradigm obtains.
"My own taste would be to say that method and culture are separate and that culture is much, much more important. But that's because I want to make method as small as possible. "
Interesting phrasing. Using two different meanings for the words, I read two different sentences in there. Using what I think are your meanings, I disagree ever so slightly. But using my meanings, I agree. Strange. What I think are your meanings are, I think, most people's meanings. It's just that I've been reconstructing the notion of methodology for the last 7 years. Ralph was the first person to use the meaning I now use.
Consider that designing a methodology is actually designing a culture to sit on/in the local culture. Then it doesn't work properly to say that "method and culture are separate." They are intertwined. It does still make sense to say that the local culture is important. I'd like to say much more important, but after watching Kent's effct at C3, I'm not sure I can. Stylistically, I prefer to let the local culture dominate, but that's a personal preference. It is possible to show up and radically restructure the local culture as part of the sw devt methodology. That's what Kent pulled off at C3.
If methodology = culture design, then what does it mean to say the "method is as small as possible"? That the culture is as small as possible? Can't say that. Culture is whatever size it is. That the interference with the pre-existing culture is as small as possible? That's my preference, too, but see the above paragraph. That the bureaucracy and paperwork are as small as possible? That's what I think you mean, and then it becomes "the method is in the lightweight methodology" category (see MinimalMethodologies). The design of the culture isn't small (see how much culture comes with XP), but the work product set is small.
As you can see, after Ralph repeated his little mantra at me for a couple of years and I finally got it, the words took a peculiar turn. Nowadays I have to listen with both lexicons running. Sorry for the long append, but the dual meaning of that sentence was just too interesting. Thanks for the compliment, by the way. Guess it comes from viewing methodology as a relative of social anthropology, and also discoving over and over that people don't do what they say they do. --AlistairCockburn
Alistair, you've made we want to think about what I mean by wanting method to be small. But there's a lot of interesting stuff here thanks, especially what I'll call the delta on the local culture. So Kent and then Ron, being extreme, descended at great speed the steepest possible gradient from overweight to lightweight (go on, MixThoseMetaphors?, it's the end of the week). Context: the project was a fixed deadline, mission critical one in desperate trouble. Not all situations will accept such radical surgery. But this also brings to mind stuff like SkunkWorks. Hmm. --RichardDrake
My version of the story, seen from a goodly distance away, is that Kent is a master of culture and cultural change. He knew one way to succeed, one that he and Ward had used before, individually and together. As I would phrase it, he decided, "Nothing from nothing is nothing.", and as he phrases it, "turned all the dials to 10." Anything good was outstanding, anything bad was terrible. Result: XP. But that's not the end of the story. He had to get the people to accept it. That's where the cultural engineering (and RonJeffries) came in. They can tell you sometime about the cultural rituals, symbols and norms they put into place. That was not a small feat of cultural engineering. The result was a new culture, an XP culture, one with an ultralight or ultralow-bureaucracy methodology. A lot a cultural change for a tiny set of work products. The cultural delta was approximately equal to the size of the culture. Again, my version of the story. Ron, Martin, Kent, etc, feel free to correct. --AlistairCockburn
Ah, but it was always your version of the story as an outsider that convinced me the most, for the reasons exemplified in the war stories in MethodologistsDontProgram. Either they had slipped something pretty potent into your drink up there in Detroit or sum'ut pretty real was going on there. The massive cultural transformation was a fantastic achievement within a very established big company culture, that goes without saying from all my experience. Kent or Ron on their own couldn't have done it, that's also clear. You are in a much better position to measure the delta and the relative contributions of the big two. (You're also closer for either of them to hit you!)
But I remain interested in the starting conditions. "Small boy with hammer" is certainly too trivial a pattern for this level of cultural breakthrough but ... I still believe that my comment at the start of ChryslerAndSteadyState was a fair one and (to be honest) that Ron's "it is more a matter of choice than anything about the domain" was more a product of euphoria at the achievements in Detroit than real experience - at that point - of the application of XP to transform projects in very different cultures under very different commercial pressures. --RichardDrake
Come on -- that's like saying everyone should be a Baptologist or a Presbyterialist.
I think I disagree with the premise of the page, as I do not think it is feasible for everyone to be a methodologist. I find I do not have the time available to be a methodologist. I do not have the time to read any more than a small sample of available information nor have the resources to do an effective evaluation of the methods I do read about. I pretty much have to rely on others to methodologists and trust them to do the job. -- WayneMack
You betcha, Wayne. In fact, that's why people like Demming, Crosby, Fagan, the QFD folk, etc., all published examples of their work and provided step-by-step instructions for how to accomplish tasks using their methods. Methodology should be simple technology driven by easy formulas, not complex religion driven by difficult principles. The hard part is sticking to the formulas and doing the work even when you don't want to. -- MartySchrader
EditText of this page
(last edited September 5, 2011)
or FindPage with title or text search