Would this have been a good philosophy for a safety-critical computerization project

[workplace psychopath]

? "I think you are completely missing the point about what a software process is and why you need software process improvements. A process is a set of REPEATABLE steps to perform a task.

If, as you say, "A programmer, or team of programmers, simply set to work, using some sort of 'programming support environment'" their process is referred to as ad hoc. It is not repeatable. It is not documented. The team has no way to indoctrinate new people. As a result, the group relies on "superheros" such as your Bob Clark. The SEI's CMMI would refer to this organization as a level 1 organization (that's as low as it gets).

Compare that to a CMMI level 3/4/5 group. Here, the processes are defined, written down, and everyone is trained in them.
For its baseline process (or more likely, processes), the organization takes the best practices from within its organization plus some any new process steps it wants to try. If the process is perfect, the group will always be on budget, on schedule, and produce software products with an acceptable number of defects. Of course, even if the process WAS perfect, that doesn't mean that the group could not be more efficent and further reduce development costs.

At some point, a group or manager will want to try something new. Perhaps there is a new tool available (a UML modeling tool or a test engine) or there is a new development methodology (Agile). The software process improvement provides a defined methodology (a process) to assess if the new process is something that the organization should adopt (and train people on). The group will define metrics that are collected on both the old and new process (defects found in the field, time to produce code).
If the new process is (statistically significant) better (by the NUMBERS), then it should be adopted. If it is worse, it should not be adopted.

At a company I used to work for, we metriced non-conformance costs. These are costs associated with not meeting the customer's requirements. They include rework, cost and schedule overruns, costs for re-releasing software, and penalties. As we went from CMM level 1 to CMMI level 3, we saw our non-conformance costs drop by over $230 million in less than 5 years.

Once again, I'm going to suggest that you look at some of the information from the Software Engineering Institute at Carnegie Mellon University. They are the experts."
Source(s):
www.sei.cmu.edu

(terrific advice from Jeffrey C. to a person who asked about "software process improvement")