Review By: Daniel Campanelli
05/21/2004In “Professional Software Development,” Steve McConnell presents an excellent overview of the current state of the software development profession. He starts by discussing the reasons why software development should be organized into a full-fledged profession much like the medical, legal, and accounting professions. His main argument is that software has become so much a part of mainstream life, that software development should be regarded as an engineering profession.

McConnell’s rationale is that software has evolved into a product produced for use by the general public. Failure of the software can have potentially serious consequences for its users. In general, it is engineers who design products for practical use by the general public using mathematical and scientific techniques. Once products are released, the engineers are held accountable for the quality of the products they design. Thus, it is argued that software development must be subjected to the same rigors as any other engineering discipline.

Some of the more salient issues cited as obstacles to the growth of the software engineering profession are as follows:

1) Software development is still taught as a scientific discipline rather that as an engineering discipline.
2) Software practitioners being ignorant of the software body of knowledge.
3) Lack of organizational maturity in the field software engineering.
4) Lack of industry regulation.
5) Practitioners still following code-and-fix development practices rather than generally accepted practices.

Conversely, some off the achievements cited as some of the more prevalent underpinnings of an emerging software engineering profession are as follows:

1) The publication of the Software Engineering Book of Knowledge (SWEBOK).
2) The publication of a Professional Code of Conduct for Software Engineers.
3) The establishment of the Software Capability Maturity (SW-CMM) Model by the Software Engineering Institute.
4) Colleges now offering a Software Engineering curriculum for the first time.
5) The IEEE offering a professional certification exam to practitioners.

The current state of the profession is that even though the above tools have existed for more than fifteen years, software development organizations have been slow to adopt them. As much as 75 percent of software development is still done in organizations that maintain a culture of “code-and fix” development. The book concludes by suggesting that an independent infrastructure is needed (i.e. as part of a software engineering profession) to transfer knowledge from research and development facilities to individual practitioners within their respective industries.

McConnell’s writing style makes for very easy reading through his excellent use of analogies and well-thought out metaphors. In this regard, he presents a very comprehensive overview of issues currently stifling the growth of the profession along with some of the initiatives that should be undertaken to address each of them. Much of his material is drawn from some of the most prevalent experts in the field of software development both past and present.

In my opinion, this book is a must read for any software quality professional. By adopting an infrastructure of a full-fledged profession, software engineering can be done in a proactive manner with well-defined expectations at each stage of the software development lifecycle. Aside from the obvious benefits of increasing productivity and personal effectiveness on software development projects, it provides an effective framework for quality professionals to effectively carry out their responsibilities of verification and validation throughout the lifecycle of any given software project.