"What developer isn't"? How about any developer who actually develops for a living? Only bean counters think that coding is a science that can be reduced to a process of any kind. Implementing a CMM process is the surest method of pissing off your developers, shackling productivity, and employing people who know nothing about development.

So if you need to employ your father's cousin's former roommate, then have at it. Otherwise, get back to coding and leave the CMM for the idiots who think it's a good idea.

"Only bean counters think that coding is a science that can be reduced to a process of any kind."

Well, if you really think that software development is a process-free area, can I recommend an El Reg teeshirt: http://www.cashncarrion.co.uk/products/16262/0/

The trouble is that those beancounters are employed by the people who pay programmers; and these paymasters expect predictable deliveery of working software that meets a business need - and seem unhappy about our ability to do this in practice.

But CMMI doesn't say that you must have process or that Maturity Level 1 (ML 1) organisations must fail. It just says that ML 1 is high risk. Probably the best example of a (very) successful low-maturity development organisation is Microsoft in the 1990s. Microsoft now seems to be interested in increasing its development process maturity, however.

Walter Riggs and David Norfolk are both right depending on the circumstances of the development.

If it is neccessary to synthesize a brand new algorithm to carry out some complex task, or perhaps find a much faster way to do something than previously achieved, then the contribution to success of process (of any form) will be relatively small. It will more or less all depend on the skill and background of the small team tackling the problem. Not that they will develop successfully with NO process, just that it can be quite light and will not be a major determining factor in success.

If on the other hand, it is neccessary to develop 500 "screens" of well-understood business processes, all dipping into a database i.e. a more or less design-free activity, then getting the 50 programmers to work together to produce consistent and working software on time, is MOSTLY process i.e. "follow the process and the results will pop out at the end". Highly skilled developers would make a somewhat better job but such skills would not be the determining factor in success.

The more innovative and synthetic (as in "synthesizing") the work, the less contribution to success is made by process simply because written process cannot substitute for skill (or we would not need teaching establishments such as universities). On the other hand, even the small team needs SOME process, if only to keep the management quiet and the CMM evaluation consultants/salesmen off their backs.