Methodological pluralism is the thesis that the use of not only multiple theoretical models but also multiple methodological approaches in the course of scientific practice is legitimate: "Given any rule, however 'fundamental' or 'necessary' for science, there are always circumstances when it is advisable not only to ignore the rule, but to adopt its opposite." -- PaulFeyerabend
According to pluralists, no approach can be ruled out for good. If, for example, a research program is mainly interested in discovery of new phenomena, a counter-inductive approach (i.e. counter-inductive with respect to current 'facts') may prove successful. However, this does not make the choice of method arbitrary. It does make the choice highly context-sensitive and a good deal more complex than some rationalists imagine.
How does this protect people against utter insanity and pure evil? Josef Mengele took a very counter-inductive approach.
Pluralistic trends in software development
But perhaps in this case it would be useful to have patterns for choosing between patterns? Metapatterns?
- Some software methodologists and practitioners are now coming to conclusions similar to those of modern day philosophers of science. The proponents of AgileSoftwareDevelopment argue that methods should not be chosen without considering the people involved (i.e. their aims, number, physical location, culture, and working environment). Nor should method and process be valued over results.
- ExtremeProgramming is a software development approach which not only acknowledges the contextual nature of advice it offers, but also suggests that the context might be changed to suit the methods of working. ExtremeProgramming does not even pretend to be a "one size fits all" methodology. It is a given that different approaches will be more or less appropriate in different contexts.
- DesignPatterns provide problem-solution pair abstractions. The generality of the abstraction is balanced by an explicit statement of the pattern's context. DesignPatterns are fully pluralistic in the sense that two patterns may be written for the same problem and context. In this situation, the rules for choosing between two patterns are unwritten.
The simple answer is to narrow the context until one solution seems more appropriate. In practice you have to try things out, skrew things up and then narrow the context.
Pluralism versus Reductionism (via simplicity)
Contrast with OccamsRazor
, which is the force pulling methodologists towards a single (hopefully 'best') theory. E.g. skeptics rule out the aliens-are-here hypothesis due to lack of evidence and lack of additional explaining power. In other words, there are some approaches which should be ruled out.
There are a number of approaches open, even to those who would like to reduce the number of theories available. Should one take the simplest theory? the theory that "explains" the most data? provides the most data? has the largest set of possible falsifying instances? has the largest collection of validating empirical evidence? most elegant?
In the philosophy of science this problem is know as the GeneralizedDemarcationProblem?. How do we know if one theory is better than another? This little conundrum has kept philosophers of science busy for decades. So yes, as you say, there are some approaches that should be ruled out. The problem is we don't have any single, agreed up-on rule for deciding how to do this in the general case.
In software development we have the added difficulty that simplicity can lead you in different directions. One approach may lead to a simple implementation, but complex user interaction. Another approach may make testing trivial, but increase the complexity of implementation. And then there are any number of sub-issues even for implementation. For example, consider increased modularity as an objective measure of simplicity (minimal lines of code per method, small source files etc.) With this measure we are almost always moving away from simplicity
in some direction; reduce the number of lines per file and we have increased the number of modules. (see ParadoxOfDimensionsOfSimplicity)
Pluralism no good for beginners
In general, I would vote against MethodologicalPluralism
. The problem is that until you become extremely knowledgeable about a method, you do not know enough to identify its short-comings. I see far too many cases where people attempt ad hoc solutions by taking a little from here and a little from there.
I prefer to pick and commit, but continue to evaluate. If you are following an approach and problems are starting to show, pick another and go for it 100%, no halvesies.
"In general, I would vote against MethodologicalPluralism
Indeed there are times when such a pluralism does not apply. But if you start by saying "In general..." then you've missed the point. The point being that "in general" you can say very much at all. Otherwise I agree with what you say. My understanding of this philosophy, is that it tries to balance and assimilate ideas rather than dismiss or transcend them with more "general" or "correct" ideas.
Pluralism results in a random approach
Very few people are in the position to use MethodologicalPluralism
. Few people have the time, knowledge, or interest to evaluate multiple methodologies. In this situation, any attempt to combine aspects of different methodologies results in a random approach.
Indeed it is the case that people usually go for what they know. As regards the "random" aspect of altering a prescribed methodology, I have difficulty believing that wholesale acceptance of a method, without considering alternatives or context (MethodologicalPurity), results in anything less arbitrary. The changes one might make to a methodology should be well reasoned changes. It does not follow that something "random" results.
"few people are in the position to use MethodologicalPluralism
" sounds like it comes from a youngster. Assume you can learn a new method every 5 years. Then after 20 years you have four very different methods. Assume you started at age 20-25. Then MethodologicalPluralism
is reached by age 45, still with 20 good years to go. What this suggests to me is that in any craft or skill, experts will have MethodologicalPluralism
in what they do. Ergo, reaching quite the contrary conclusion, "many people are in the position to use MethodologicalPluralism
Trust the experts
Trust the people who have put together a methodology to have made it correct and complete. One should not let his instincts overrule others' knowledge. Unless one is a knowledgeable expert on multiple methodologies, one is better off using MethodologicalPurity
One may "trust the people who have put together a methodology" and assume that their methods successfully met the problems found in the situations they were designed for. To go further and assume that their methodology is "complete" (i.e that they designed it also with one's specific cultural, political, economical or technological situation in mind) is taking things a step too far. The view that one should not let instincts overrule expert knowledge is unashamedly elitist. Even most simple advise, from experts or otherwise, cannot be used out-of-the-box, but has to be interpreted and then adapted to the problem at hand. Only one's instincts will tell whether one has understood the advice. Only one's own good-sense will tell whether one is doing things wrong. If this can't be done, then indeed one needs an expert.
I believe the title of this section may be misleading. Just because someone has put together a methodology does not imply he is an "expert" or even knowledgeable in programming. The reality is that a vast majority of corporate software development methodologies were put together by QA departments with no understanding of actual programming. Do not rely in either blind acceptance or blind rejection of a methodology, but understand its strengths and weaknesses. It is fair to question why a part of a methodology is beneficial and those who produced it should be able to justify their rationale with something more than: "try it, you'll like it," "it is an industry best practice," or "because we say so."
tries to co-exist with other more conservative methodologies. TGP focus on the "hot" likely to change modules and suggests that the cold modules will be developed by traditional methods. See OtherMethodologiesAndTgp