Аннотация

In the late 1960s, the need for computer software was outpacing the capability of technical schools, colleges, and universities to produce trained computer professionals to create that software—a phenomenon that became known as the software crisis. Increasing the output of colleges and universities wasn’t a practical approach; too few qualified students were enrolling in computer science programs to satisfy the demand. At the time, researchers determined that a better solution was to increase the productivity of existing computer programmers. Noticing similarities between software development and other engineering activities, these researchers concluded that the procedures and policies that worked for other engineering disciplines could solve the software crisis. Thus, software engineering was born.
Until the field of software engineering blossomed, software development was a mysterious craft practiced by gurus with varying abilities and accomplishments. Up to that point, a software project’s success depended entirely upon the abilities of one or two key programmers rather than those of the entire team. Software engineering sought to balance the skills of software teams to make them more productive and less reliant upon those one or two highly talented individuals.
To a large extent, the practice of software engineering has been successful. Large projects built by teams of programmers could never have been completed with the ad hoc organizational methods of the past. But at the same time, important qualities were lost. Software engineering encourages team productivity at the expense of individual creativity, skill, and growth. Although software engineering techniques have the potential to turn poor programmers into good programmers, they can also restrict great programmers from doing their best work. The world has too few great programmers. The last thing we want to do is to discourage a programmer from reaching their potential; however, this is what the software engineering regimen often does.
The Write Great Code series is an effort to restore some of that lost individual creativity, skill, and growth. It covers what I call personal software engineering, or how a programmer can improve the quality of their code. Specifically, it describes how you can produce great code—code that’s easy to maintain, enhance, test and debug, document, deploy, and even retire—from mediocre code. Great code is devoid of the kludges and hacks that are often the result of unreasonable pressure or ill planning on the engineer’s or management’s part. Great code is code you can be proud of.
As I completed Write Great Code, Volume 2: Thinking Low-Level, Writing High-Level (WGC2), I had intended to incorporate more information in this book. In the last chapter of WGC2, I wrote the following:
[Write Great Code, Volume 3: Engineering Software] begins discussing the personal software engineering aspects of programming. The software engineering field focuses primarily on the management of large software systems. Personal software engineering, on the other hand, covers those topics germane to writing great code at a personal level—craftsmanship, art, and pride in workmanship. So, in Engineering Software, we’ll consider those aspects through discussions on software development metaphors, software developer metaphors, and system documentation [emphasis added], among other topics.
System documentation (including requirements, test procedures, design documents, and the like) is a huge part of software engineering. Therefore, a book on the subject must provide, at the very least, an overview of these subjects. Well, about seven chapters into this book I realized there wasn’t enough room to cover all this material in a single book. In the end, I wound up splitting this volume, Engineering Software, into four volumes. The first of these four volumes is this one, which is the third volume of the Write Great Code series. It concentrates on software development models and system documentation. The fourth volume of the series will teach software design; the fifth volume will develop the great-coding theme further; and a sixth volume will deal with testing.
As I write this, it’s been 10 years since I completed Volume 2 of the Write Great Code series. It was time to complete Volume 3, even if it meant splitting the original information across two or more volumes. If you’ve read my earlier books, you know I like to cover subjects in depth; I’m not interested in writing books that barely touch on the subject matter. Thus, I was faced with either splitting the work across multiple volumes and getting them out the door or producing a 2,000-page tome that, as history has oft demonstrated, might never be completed. I apologize to those who expected this book to cover additional subjects. Fear not—the information will arrive in future volumes. You’re just getting the first part of it sooner in this book.