Feyerabend On Software

TheFeyerabendProject is an attempt by RichardGabriel "to repair the arena of software development and practice". The project is possibly coming to the inevitable conclusion that Feyerabend has very little advice to offer software developers. That shouldn't be a surprise. After all he never gave us a mention. The following is often quoted:

: ...one of the most striking features of recent discussions in the history and philosophy of science is the realization that events and developments ... occurred only because some thinkers either decided not to be bound by certain 'obvious' methodological rules, or because they unwittingly broke them.
: This liberal practice, I repeat, is not just a fact of the history of science. It is both reasonable and absolutely necessary for the growth of knowledge. More specifically, one can show the following: 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

The biggest problem in the area of software practice is, in fact, lack of general software development know how. Sure there are stubborn myths and PeopleWare points out some of the rules where we should "adopt its opposite". But you have to get people's attention first. I sometimes feel that there are just not enough people in our industry interested in bettering themselves as developers.

Of course, you could always treat the many AntiPatterns in the industry to be rules. Things like C syntax (C, C++, Java), compatibility before everything, ArmyOfProgrammers, et cetera et cetera. But that gets you to the idea that OO is good, compatibility shouldn't matter (that's what emulation is for), hire programmers who know the highest-level languages possible (LispLanguage, SmalltalkLanguage). It's only around here that these topics will produce big yawns of boredom.

Can't really see how this applies to software. We know that iterative development is necessary, perhaps even fundamental to what we do. As for rules where it might be better off to adopt their opposite, I have a hard time thinking of a single well ingrained rule where you might want to adopt its exact opposite. There are bad rules (leading to anti-patterns e.g. AnalysisParalysis). There are things you might want to do instead. What, though, would the point be of not doing any analysis. Conclusion: the quote above and perhaps the whole FeyerabendProject? is a victim of its own rhetoric. --AnonymousDonor

"I have a hard time thinking of a single well ingrained rule where you might want to adopt its exact opposite"

Well let me give you an idea of what is meant. The examples I have in mind are so familiar, you might be forgiven for having missed them. In stark opposition to earlier methodologies XP and Agile de-emphasize documentation. At another level, but within the same community, there is a shift from statically to dynamically typed languages. A shift which was previously heading the opposite direction.

When it comes to breaking "certain 'obvious' methodological rules", XP is unmistakably laughing in the face of the methodologists. As for iterations, it is by no means clear that iterative development fits well with research. --ChrisSteinbach

Could you expand on that last point? It's pretty clear to me that research not only fits well with iterative development, it demands it. -- JosephDale

For sure you refine ideas during research, but that's not all you do. Ideas are thought out then rejected in whole or in part, then reconsidered and so on. Iteratively refining ideas must happen, but to what extent? Is there a rule for this?

A reply to this might be "OK, but incremental development is necessary for research". And again I would ask, to what extent? Research, more than anything, delivers value in fits and spurts. How, for example, would you control the scope of any given increment? --ChrisSteinbach