CMMI and Other Methods of Producing Mediocre Systems
First, let me say that I just started writing this essay and my thinking is incomplete on it. I hope to finish it this summer (2009).
CMMI
Twenty or 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 firms 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 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 fairly good at enabling organizations to produce quality systems, they do so by reducing the production process to a discrete set of tasks that ensure that basic checks are in place to prevent very poor quality work, but have the side effect of saddling very creative, intelligent, and enthusiastic engineers with ridiculous numbers of constraints and driving these people away to other, less regulated projects, leaving the CMM projects with a shortage of real talent and ensuring that they will produce generally mediocre systems. Note that I’ve worked for two (much better than average) engineering companies that implemented CMM level 3 and CMMI level 5, so I have actual experience at 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 of less than average technical skill can create “functional” applications using currently available programming tools. Let’s examine Microsoft as exhibit A. Microsoft is incapable of producing an elegant and highly functional operating system or applications of its own. It attempts to make up for this deficiency by producing inelegant and dumbed down but relatively simple tools for building application 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 two brain cells to rub together to produce software for use on Windows, and thereby conquer the superior OS-X and other operating environments through sheer force of numbers. Unfortunately, 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.
