I often read in books a phrase akin to "Although there is no silver bullet methodology/practice, there are many techniques that can solve the software crisis, the problem is they are unused or little-known"

Well I'm tired of hearing that phrase and not having it backed up with examples. I'm slowly becoming convinced no such techniques exist, and the statement is always left open so the author can advocate their particular methodology/practice. It's easy to simply advocate one's particular flavor(i.e. ExtremeProgramming, OOP, RationalUnifiedProcess, etc) as though it is a common practice that others simply haven't discovered yet.

So I'm curious, do such practices exist? If so, are they all relative? How can the mainstream ever start using the techniques when they always seem in conflict or motivated by personal factors?

''The quote is lying through its teeth via self-contradiction. Anything that even ameliorates, let alones solves, the software crisis, is the very '''definition''' of a SilverBullet. But yes, plent of people try to have it both ways, and basically say "sure, everyone knows ThereAreNoSilverBullets, sure, right, I'm not saying otherwise, but let me tell you about my SilverBullet."''

''I.e. it's always self-serving marketing B.S. If someone has a SilverBullet, let them come forth and be brave about claiming it.''

''To be fair, I think on the other hand this is like Englebart's fabled BrickifiedPencil study: there are plenty of AntiSilverBullet approaches that make the software crisis '''worse'''. So many methodologies are important, not to solve anything (which is beyond the state of the art), but just to keep them from being a complete disaster.''

''So for instance, testing methodologies aren't SilverBullets, but nonetheless you'll run into trouble if you skip them. Etc. -- DougMerritt''

Isn't that a paradox? Say a developer doesn't use any testing methodology. . he then wants something to "ameliorate the problem" - so he implements a testing methodology. It helps, therefore it's a SilverBullet, right? So maybe a SilverBullet doesn't exist, but Anti-Anti-SilverBullets might? As in, "software engineering's knowledge is all in negative space, there is nothing in the positive space" or "There are no guidelines for doing things right, just guidelines for not doing things wrong"

''Not at all. Exact analogy: there's a difference between making money versus finding ways to lose less money. Both are important, both go in the direction of more positive rather than more negative profits, but in the limit, the most money you can make by avoiding losses is zero. Zero is much better than negative, but zero is not a positive profit. Same thing here. Shifting from assembler to a higher level language was a clear SilverBullet of the past. Productivity went up, etc. We want another clear net positive result, but it's good not to waste whatever positive we have, too.''

''Incidentally I had forgotten that Brooks defined a SilverBullet to be a 10x improvement. I think that's arbitrary, and it doesn't change my overall point too much, but I suppose it's harsh for me to imply that there aren't any methodologies that will net even, say, 10% productivity gains. There are, and they should be used, but I find it annoying for people to act like 10% is 10x. -- DougMerritt''

It's not a binary thing; all methodologies aren't either exploding guns or silver bullets.  There are blanks, duds, just plain bullets, bb's, .22s, .45s, semiautomatic, incredibly expensive but effectice (if overkill) nukes, and everything else.  The mapping of methodology to ammo is largely WhateverWorksForYou.

''and to think I got into computing because I thought it was logical and digital, then I find out it's all MassHallucination and analog''

We feel for you. What a dreadful disappointment. Alas, lost innocence.

''I guess I always knew. . . what's the stage after denial again?''
* Forgetfulness. ;-)
* T''''''heGreatUnknown.