''Problem:'' A software team is not delivering.

''Forces:''
	* You are under pressure to change something, because the project is clearly broken.
	* A book (or vendor!) promises Methodology X will decrease design time, remove bugs, and cure hemorrhoids without surgery. 
	* If only you didn't have all these idiots to contend with, you could get some work done.  Maybe if you tell them exactly how to do the job, they'll do it right.

''Solution:''
	* Develop a comprehensive process, based on Methodology X, plus a few good ideas of your own.
	* Develop a  style guide that lists all possible errors and warns against them.

''What Happens Next:''
	* You spend weeks in process and style meetings arguing.  In each meeting, you attempt to prevent all possible mistakes that a naive or malignant coder could make.  Next, you then argue about whether a given mistake is really always a mistake, or is sometimes a good idea.  You begin to doubt the competence of everybody in the meeting, including yourself.
	* The style and process guide, when complete, is thicker than the CRC and much less useful.
	* The quality of project code doesn't go up perceptibly.

''Lessons Learned:''

	* You cannot develop an idiot-proof process.  A good process depends on good developers to execute it. 
	* Process is no substitute for training or hiring
	* The shorter the document, the more it is read.
	* There are no silver bullets.
----
Quotes:

* "It is impossible to make anything foolproof, because fools are so ingenious." --RobertHeinlein
* "Those who try to build idiot-proof systems always underestimate the persistence and ingenuity of idiots." --anon
* "If you make your system more idiot-proof the idiots will build a bigger idiot" --anon
* "You can make something foolproof, but not damnfoolproof" --anon
----
''"You can't make a silk purse from a sow's ear."''

No matter what you do, BadProgrammer''''''s will produce BadCode. Not to say that they can't be turned into good programmers...but they have to want to be better.

''What you can do, however, is arrange for those bad programmers to produce their code on someone else's project.''
----
''If you create a system that any idiot can use, then only idiots will find it useful.''

Making a process idiot-proof requires that you make it impossible for the users to make a "bad decision".  You do this by either removing all decision-making from the process, limiting choices to a set of known-safe alternatives, or by assigning all decisions to someone assumed to not be an idiot.  This eliminates creativity and restricts the users' actions. But it is a HumaneInterface.
----
Without strict guidance, the idiot is expected to make mistakes. But detailed instructions don't scale up from the limited scope of cooking recipes or travel directions, that the idiot can (more or less) understand and carry out easily from the comfort of a short text and of short term memory, to the huge scope of a software development process: the idiot is very unlikely to understand it, has trouble looking things up, and cannot possibly remember all the process details.
Therefore, trying to counter incompetence and dumbness by adding detail is rather fruitless.
----
"Campaigns to bearproof all garbage containers in wild areas have been difficult because, as one biologist put it, 'There is a considerable overlap between the intelligence levels of the smartest bears and the dumbest tourists'."
----
How is it possible that you guys could so thoroughly miss the mark? When you ignore the science behind "best practices" processes and the solutions provided by professionals then you end up with chaos and hopelessness. Ignore those methodologies that have proven effective at your own peril. Saying that methodologies never work is simple and ignorant naysaying. Watch out for the dustbin of history -- there's a slot reserved there for you.
----
CategoryAntiPattern, CategoryQuote