Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

After the Gold Rush:
Creating a True Profession of Software Engineering

by Steve McConnell

Microsoft Press, 1999

Trade paper, 182 pages

Steve McConnell makes three points in After the Gold Rush: Creating a True

Profession of Software Engineering (Microsoft Press, 1999.): First,

code-and-fix may have been an acceptable or even necessary development style

during the infancy of software development, but it's no longer defensible.

Second, the cure for code-and-fix is a rigorous adherence to generally

accepted engineering principles, applying those principles as software

engineering. And, finally, there is a need for software engineering to be

recognized as a true profession, analogous to civil engineers or electrical

engineers, that is quite distinct from the concept of a computer scientist.

I can't help but agree with all of those points, particularly the third one.

When I went to college, computer scientists wrote software and programmed

the computers that the electrical engineers had built. Although I'm a

computer scientist on paper, as a developer, I built applications for

organizations to use, rather than conducting research to extend the software

community's body of knowledge. Designing and building things--bridges,

radios, applications-- is a function of engineering, not science.

McConnell makes those points and more. His very readable After the Gold Rush

examines the state of today's software development and touts many of the

usual statistics about the percentage of software projects that fail, go

over budget, and so on. The parade of numbers does lay the groundwork and

provide a sense of urgency for moving from code-and-fix to software

engineering, but alas, failed to totally captivate me. Some readers may

abandon ship at that point, which would be unfortunate.

The most compelling section of the book is where McConnell differentiates

software engineering from computer science by comparing and contrasting it

to more traditional engineering disciplines. He reveals much about current

governmental and academic initiatives to recognize software engineering as a

true profession, such as the Professional Engineer (PE) certification from

Texas. McConnell also suggests metrics for determining the state of software

engineering as a profession: specific higher education programs in software

engineering, the accreditation of schools offering such training, a

curriculum for lifelong continuing education, certification of development

organizations, licensing of engineers, professional societies that advance

the art and a code of ethics with teeth.

The connection between McConnell's goal of a certified software engineer as

a solution to the problems described in the first part of the book is

tenuous. It's true that organizations applying an engineering-styled

approach to their software development efforts often achieve better results.

But will the creation of a professional software engineer make the

difference in other organizations?

In the engineering model that McConnell imagines, certified development

shops will employ a handful of certified software engineers. Those engineers

will oversee the work of a much larger mass of noncertified software

technicians and specialists, and will be being required to sign off on

application requirements, design, coding, testing and maintenance--and if

need be, stand up to corporate management's insistence on cutting costs and

accelerating schedules. McConnell believes, but does not prove, that such a

model will work in the fast-evolving field of software development.

In a similar vein, I believe that McConnell is optimistic when assessing the

maturity of the today's software development practices. Certified

professionals such as civil engineers, doctors and lawyers have

long-standing traditions and generally accepted principles that society as a

whole recognizes. Are software developers as well understood? I don't think

so. McConnell also asserts that today, "about 50 percent of the software

engineering body of knowledge is stable and will still be relevant 30 years

from now." My vote: maybe 10 to 15 percent.

But that's quibbling. Whether the time is right or not, the underlying thesis

behind After the Gold Rush is sound. Society needs professional standards,

so that an employer or customer understands precisely what a software engineer

can and can't do. And for that reason, this book advances the software-engineering

discussion to the next level. Whether you agree or disagree with McConnell's

assertions and predictions, he's certainly given us a reference point that we

should think and talk about.

RELATED ARTICLES Wind River Hypervisor 1.1 Released Parallel Pattern 5: Stencil Distributing Work Across Cores Using .NET Other Voices: Knowledge Management Basics Inform System Release Lifecycle Server+client Fusion: An Architectual Proposal		TOP 5 ARTICLES No Top Articles.