Preface
My primary concern in writing this book has been to narrow the gap between the knowledge of industry gurus and professors on the one hand and common commercial practice on the other. Many powerful programming techniques hide in journals and academic papers for years before trickling down to the programming public. Although leading-edge software-development practice has advanced rapidly in recent years, common practice hasn't. Many programs are still buggy, late, and over budget, and many fail to satisfy the needs of their users. Researchers in both industrial and academic settings have discovered effective practices that eliminate most of the programming problems that were prevalent in the seventies and eighties. Because these practices aren't often reported outside the pages of highly specialized technical journals, however, most programming organizations aren't yet using them in the nineties. Sridhar Raghavan and Donald Chand found that it typically takes 5 to 15 years for a research development to amble into commercial practice (1989). This handbook shortcuts the process, making key discoveries available to the average programmer now. Who Should Read this Book?The research and programming experience that has been collected in this handbook will help you to create higher-quality software and to do your work more quickly and with fewer problems. This book will give you insight into why you've had problems in the past and will show you how to avoid them in the future. The programming practices described here will help you keep big projects under control and help you maintain and modify software successfully as the demands of your projects change. Experienced programmers This handbook serves experienced programmers who want a comprehensive, easily accessed guide to software construction. Because this book focuses on implementation, the part of the software development cycle familiar to all programmers, it makes powerful software-development techniques understandable to self-taught programmers as well as to programmers with formal training. Self-taught programmers If you haven't had much formal training, you're in good company. About 100,000 new programmers enter the profession each year (Boehm and Pappaccio 1988), but only about 40,000 computer-science degrees are awarded each year (NCES 1991). From these figures, it's a short hop to the conclusion that most programmers don't receive a formal education in software development. Many self-taught programmers are found in the emerging group of professionals--engineers, accountants, teachers, scientists, and small-business owners--who program as part of their jobs but who do not necessarily view themselves as programmers. Regardless of the extent of your programming education, this handbook can give you insight into effective programming practices. Students The counterpoint to the programmer with experience but little formal training is the fresh college graduate. The recent graduate is often rich in theoretical knowledge but poor in the practical know-how that goes into building production programs. The practical lore of good coding is often passed down slowly in the ritualistic tribal dances of systems architects, analysts, project leads, and more experienced programmers. Even more often, it's the product of the individual programmer's trials and errors. This book is an alternative to the slow workings of the traditional intellectual potlatch. It pulls together helpful tips and effective development strategies previously available mainly by hunting and gathering from other people's experience. It's a hand up for the student who is making the transition from an academic environment to a professional one. Key Benefits of This HandbookWhatever your background, this book can help you improve your software-development skills: Complete software-construction reference. This handbook discusses general aspects of construction such as software quality and ways to think about programming. It gets into nitty-gritty construction details such as steps in building a routine, ins and outs of using data and control structures, debugging, and code-tuning strategies and techniques. And you don't need to read it cover-to-cover to learn about these topics. This book is designed to make it easy to find the specific information that interests you. Read-to-use checklists. This book includes checklists you can use to assess your software architecture, design approach, module and routine quality, variable names, control structures, layout, test cases, and much more. State-of-the-art information. This handbook describes some of the most up-to-date techniques available, many of which have not yet made it into common use. Because this book draws from both practice and research, the techniques it describes will remain useful for years. Larger perspective on software development. This book will give you a chance to rise above the fray of day-to-day fire fighting and figure out what works and what doesn't. Few practicing programmers have the time to read through the dozens of software-engineering books and the hundreds of journal articles that have been distilled into this handbook. The research and real-world experience gathered into this handbook will inform and stimulate your thinking about your projects, enabling you to take strategic action so that you don't have to fight the same battles again and again. Concepts applicable to any procedural language. This book describes techniques you can use to make the best of whatever language you're using, whether it's Pascal, C, C++, Ada, Basic, Fortran, Cobol, or another procedural language. Code examples. The book contains about 500 examples of good and bad code. I've included so many examples because I learn best from examples. I think many other programmers learn best that way too. The examples are in multiple languages because mastering more than one language is usually a watershed in the career of a professional programmer. Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly make a difference in quality and productivity. In order to make the multiple-language burden as light as possible, I've avoided esoteric language features except where they're specifically discussed. You don't need to understand every nuance of the code fragments to understand the points they're making. If you focus on the point being illustrated, you'll find that you can read the code regardless of the language. I've tried to make your job even easier by annotating the significant parts of the examples. Access to other sources of information. This book collects much of the available information on software construction for you, but it's hardly the last word. Throughout the chapters, "Further Reading" sections describe other books and articles that you can read as you pursue the topics you find most interesting. Where Else Can You Find This Information?This book synthesizes development techniques from a variety of sources. In addition to being widely scattered, much of the accumulated wisdom about construction resides outside written sources (Hildebrand 1989). There is nothing mysterious about the effective, high-powered programming techniques used by expert programmers. In the day-to-day rush of grinding out the latest project, however, few experts take the time to share what they have learned. Consequently, programmers may have difficulty finding a good source of programming information. The techniques described in this book fill the void after introductory and advanced programming texts. After you have read Introduction to C, Advanced C, and Advanced Advanced C, what book do you read to learn more about programming? You could read books about the details of PC, Macintosh, or Unix hardware or operating-system functions, or books about another programming language-you can't use a language or program in an environment without a good reference to such details. But this is one of the few books that discusses programming per se. Some of the most beneficial programming aids are practices that you can use regardless of the environment or language you're working in. Other books generally neglect such practices, which is why this book concentrates on them. The only other way to obtain the information you'll find in this handbook would be to plow through a mountain of books and a few hundred technical journals and then add a signficant amount of real-world experience. If you've already done all that, you can still benefit from this book's collecting the information in one place for easy reference. Why this Handbook was WrittenThe need for development handbooks that capture knowledge about effective development practices is well-recognized in the software-engineering community. A report of the Computer Science and Technology Board stated that the biggest gains in software-development quality and productivity will come from codifying, unifying and distributing existing knowledge about effective software-development practices (CSTB 1990). The board concluded that the strategy for spreading that knowledge should be built on the concept of software-engineering handbooks. The history of computer programming provides more insight into the particular need for a handbook on software construction. The Topic of Construction has been Neglected At one time, software development and coding were thought to be one and the same. But as distinct activities in the software-development life-cycle have been identified, the best minds in the field have spent their time analyzing and debating methods of project management, requirements analysis, design, and testing. The rush to study these newly identified areas has left code construction as the neglected stepchild of software development. The neglect of code construction has been exacerbated by the treatment of coding as the dirtiest grunt work of the software-development world. An entry-level programmer in a large organization is typically assigned to code routines that have been specified and designed by someone higher up on the corporate ladder. After a few years, the programmer will be promoted to requirements analysis or project management, and a few years after that may proclaim with pride that it has been years since he or she has had to write any code. Construction is Important Another reason that construction has been neglected by researchers and writers recently is the mistaken idea that, compared to other software development activities, construction is a relatively mechanical process that presents little opportunity for improvement. Nothing could be further from the truth. Construction typically makes up about 80 percent of the effort on small projects and 50 percent on medium projects. Construction accounts for about 75 percent of the errors on small projects and 50 to 75 percent on medium and large projects. Any activity that accounts for 50 to 75 percent of the errors presents a clear opportunity for improvement. Some commentators have suggested that although construction errors account for a high percentage of total errors, construction errors tend to be less expensive to fix than those caused by analysis and design, the suggestion being that they are therefore less important. The claim that construction errors cost less to fix is true but misleading because the cost of not fixing them can be incredibly expensive. Gerald Weinberg reported that the three most expensive programming errors of all time cost hundreds of millions of dollars each and that each was a one-line, coding-level mistake (1983). Errors in those single lines might be less expensive to fix than errors in analysis or architecture, but an inexpensive cost-to-fix obviously does not imply that correcting them should be a low priority. The irony of the shift in focus away from construction is that construction is the only activity that's guaranteed to be done. Requirements can be assumed rather than analyzed; architecture can be shortchanged rather than designed; and system testing can be abbreviated or skipped rather than fully planned and executed. But if there's going to be a program, there has to be construction, and that makes construction a uniquely fruitful area in which to improve development practices. No Comparable Book is Available In light of construction's obvious importance, I was sure that someone else would already have written a book on effective construction practices. The need for a book about how to program effectively seemed obvious. But I found that only a few books had been written about construction and then only on parts of the topic. Some were written 15 years ago or more and employed relatively exotic languages such as ALGOL, PL/I, and Ratfor. Some were written by professors who were not actually writing production code. The professors wrote about techniques that worked for student projects, but they often had little idea how the techniques would play out in full-scale development environments. Still other books trumpeted the authors' newest favorite methodologies but ignored the huge repository of mature practices that have proven their effectiveness over time. In short, I couldn't find any book that had even attempted to capture the body of practical techniques available from professional experience, industry research, and academia. The discussion needed to be brought up to date for current programming languages, interactive environments, and leading-edge development practices. It seemed clear that a book about programming needed to be written by someone who was knowledgeable about the theoretical state of the art but who was also building enough production code to appreciate the state of the practice. I conceived this book as a full discussion about code construction--from one programmer to another. This material is Copyright © 1993 by Steven C. McConnell. All Rights Reserved.
|
Email me at stevemcc@construx.com.