Raising Your Software Consciousness
Steve McConnell, Construx Software
In 1970, Charles Reich published a best-selling book called The Greening of America.1 In it, Reich identifies three kinds of awareness or consciousness, which he calls Consciousness I, Consciousness II, and Consciousness III.
Consciousness I ("Con I") is the pioneer mentality. People who operate at Con I place great value on independence and self-satisfaction. They don't easily tolerate other people telling them what to do. They are highly self-reliant and self-sufficient. Reich believes that Con I dominated the American psyche during America's first centuries and that this focus on self-reliance was a significant factor in America's development.
Consciousness II is the gray flannel suit mentality—corporation man. People who operate at Con II understand the importance of getting along with others and playing by the rules. They believe rules are good for society, and they think everyone should follow them. Reich believes that Con II became more dominant than Con I in the mid-twentieth century.
Consciousness III is the mentality of enlightened independence. The Con III person operates on the basis of principles, with little regard for the rules that predominate in Con II and without the selfishness that predominates in Con I. By the time Greening was published, Reich argued that Con II's time was over. He believed Con III was in its ascendancy and would soon replace Con II.
Although The Greening of America struck a resonant chord when it was published, history has not been kind to the book. In 1999, Slate magazine's readers voted it the silliest book of the 20th century. Reich's Con III was a hippie nirvana, and the "greening" Reich predicted was a nationwide movement toward the hippie culture of the 1960s and 1970s-psychedelic drugs, bell-bottom pants, and all. As the hippie culture faded into obscurity in the 1980s, so did the credibility of Reich's predictions.
Can't Get No Satisfaction
Reich's political predictions may not have withstood the test of time, but his classification of Con I, Con II, and Con III provides a useful model for the software industry today.
Con I in software is associated with a focus on self-reliance. Software experts often refer to software developers operating at this level of awareness as mavericks, cowboy programmers, Lone Rangers, and prima donnas. Software developers at this level tend to have little tolerance for other people's ideas. They like to work alone. They don't like following standards. The "Not Invented Here" syndrome thrives.
Con I's advantage is that little training is needed, and the lone-wolf approach works adequately in environments that employ only small numbers of programmers who work independently on small projects. Con I's disadvantage is that it scales poorly to projects that need teams of programmers rather than isolated individuals.
Con II in software is associated with a focus on rules. Many software developers eventually discover the limitations of Con I's self-reliant development style and see the advantages of working in groups. Over time, they learn rules that allow them to coordinate their work with others. Some groups of developers create their own informal rules through trial and error, and these groups can be highly effective. Other groups buy a prebuilt methodology. Sometimes the rules are provided by consultants, as in the classic "17 three-ring binders" methodologies. Other times, the rules are taken from books, such as The Rational Unified Process,2 the Extreme Programming series,3 or my own Software Project Survival Guide.4 Developers at this level of awareness tend to focus on the details of adhering to the rules. They argue about which interpretations of the rules are correct and focus on "following the methodology."
The advantage of Con II is that a developer needs to be trained to use only a single approach. If a good approach is chosen, the developer can leverage a relatively small amount of training across many projects. The disadvantage is that a Con II developer is ill-equipped to succeed on projects that fall outside the specific methodology in which the developer was trained.
Con III in software is associated with a focus on principles. At this level of awareness, developers understand that the rules of any prepackaged methodology are, at best, approximations of principles. Those approximations might apply most of the time, but they won't apply all of the time. The disadvantage of Con III is that extensive education and training are needed to introduce a developer to the principles underlying effective software development, and that training is not easily obtained. Con III's advantage is that, once that training has been obtained, the developer is equipped with a full range of software engineering tools that support success on a wide range of projects.
Love the One You're with
The software industry has a long history of trying and ultimately rejecting "one size fits all" methodologies. These methodologies are Con II software approaches, and they fail outside narrowly defined areas of applicability—predictably—precisely because they are Con II. The world of software is far too varied to be addressed by a single set of rules.
For example, compare the practices you would use to develop a heart pacemaker control to those you would use to develop a video store management program. If a software malfunction caused you to lose one video out of 1,000, it might affect the store's profitability by a fraction of a percent, but the impact is negligible. If a malfunction caused one pacemaker out of 1,000 to fail, however, you've got a real problem. Generally speaking, widely distributed products must be developed more carefully than narrowly distributed ones. Products whose reliability is important must be developed more carefully than products whose reliability doesn't much matter.
These different kinds of software require different development practices. Practices that would be considered to be overly rigorous, bureaucratic, and cumbersome for video store management software might be considered irresponsibly quick and dirty—or reckless—for an embedded pacemaker control. The Con III developer will use different practices to develop a heart pacemaker control than to develop an video inventory tracking system. The Con II developer will try to apply a one-size-fits-all methodology to both projects, with the likelihood that the methodology won't work particularly well for either one.
Are You Experienced?
Reich identified the three levels of consciousness as the zeitgeists of different eras, but I see Con I, Con II, and Con III as three distinct steps along a path of personal software engineering maturity. Most software developers begin their careers at Con I and eventually journey to Con II. In many environments, Con II supports effective work, and no further development is needed. In some environments, however, a further progression toward Con III is needed.
The by-the-book methodologies of Con II seem to be a reasonable learning path for developers at Con I who are not yet well versed in a wide range of software practices. The specific details of the rules-based practices probably don't matter all that much. People who are trying to raise themselves from Con I to Con II simply need to take a first step away from the chaos of a completely unmanaged project. They must learn a set of rules and get some experience applying those rules before they can advance to the Con III level, where they understand software project dynamics well enough to break the rules when needed. This whole process is part of the natural progression from apprentice to journeyman to master.
Steve McConnell is CEO and chief engineer at Construx Software. Contact him at stevemcc@construx.com.
References
- [1] C. Reich, The Greening of America, Random House, New York, 1970.
- [2] P. Kruchten, The Rational Unified Process: An Introduction, 2nd ed., Addison-Wesley, Reading, Mass., 2000.
- [3] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, Reading, Mass., 2000.
- [4] S. McConnell, Software Project Survival Guide, Microsoft Press, Redmond, Wash., 1998.
Reprinted from IEEE Software, vol. 18, no. 6, November/December 2001, pp. 7-9.
