CMMI

Thirty years ago, the young field of software engineering was dominated by very bright people because people of average intelligence just couldn’t understand the concepts or contribute to the effort required to create a working system. Partly due to the immaturity of the field, a large number of systems engineering attempts failed to produce viable systems, resulting in a “crisis” of sorts, where the major customers capable of funding large-scale engineering efforts lost confidence in the ability of engineering teams to reliably produce working systems. The federal government and other large computing customers were tired of shoveling buckets of money into efforts that yielded (mostly) either highly flawed systems or outright failures and these customers rightly looked for a solution to this problem.

Unfortunately, the solution the software engineering community came up with may be worse than the problem. There have been a number of committee based standard solutions intended to address the problem of how to build quality software and hardware systems. Like most such efforts, the CMM, CMMI, and similar standards were intended to systematize the process of producing quality systems and because of real-world constraints, these standards assume that the average person involved in building a system is one step above a drooling moron. While CMMI and similar standards are effective at enabling organizations to produce usable, medium quality systems, they do so by reducing the production process to a discrete set of tasks and ensuring that basic checks are in place to prevent poor quality work. This sounds like a desirable mechanism to have. The cost for using this type of process is that very creative, intelligent, and enthusiastic engineers are saddled with (to them) ridiculous numbers of constraints and these people often flee to other, less process-driven projects, leaving the CMMI-using projects with a shortage of real talent and ensuring that they will produce generally mediocre systems. Note that I’ve worked on teams that had free reign (with reasonable constraints) to produce excellent systems and also those that implemented CMM level 3 and CMMI level 5 processes, so I have real world experience using these standards and I have seen the results.

Microsoft

Consider also the trend toward higher and higher levels of abstraction in programming languages, partly for the purpose of making it easier to build applications. One result of this trend is that a person with very little technical skill can create “functional” applications using currently available programming tools. Microsoft will serve as exhibit A. Microsoft is incapable of producing elegant and highly functional operating systems or applications on its own. It attempts to make up for this deficiency by producing inelegant but relatively simple tools for building applications that run on its operating systems. Visual Basic is a case in point. It is basically the Tinker Toys of programming languages (no offense to Tinker Toys intended) and it allows people with no understanding of how computers work to produce “working” programs en masse. Thus, Microsoft’s strategy seems to be to enable anyone with a modicum of intelligence to produce software for use on Windows. Superior operating environments such as OS-X are marginalized by the sheer numbers of applications available on Microsoft Windows. This strategy, combined with a very liberal advertising budget, the inertia inherent in human nature, and Microsoft’s perpetual spewing of untruths about its competitors, has allowed Microsoft to dominate the computing mass market for the last 15 years.

Summary

The way to produce high quality software and hardware systems has not changed since the 1970s. You bring together the brightest people you can find, pay them well, give them all the tools and other resources they ask for, tell them basically what you want built, and then stand back and let them work, for as long as it takes.

We should ask ourselves as a society whether the mass production of generally mediocre systems built by large numbers of people with moderate intelligence and minimal skill is really what we want. The price we pay, mediocrity as the new engineering standard, seems too high to me, and I suspect the cost will only grow as standards continue to decline in order to allow companies to continue filling their ranks with “engineers” capable of meeting the latest standard.