Preface

What's this book all about? Well, it's about how to develop software, from a personal perspective. We'll look at what it means for you to take a problem and produce a program to solve it from beginning to end. That said, this book focuses a lot on design. How do you design software? What things do you take into account? What makes a good design? What methods and processes are there to designing software? Is designing small programs different from designing large ones? How can you tell a good design from a bad one?

Next, it's about code construction. How do you write programs and make them work? “What,” you say? “I've already written eight gazillion programs! Of course I know how to write code!” Well, in this book, we'll explore what you already do, and we'll investigate ways to improve on that. We'll spend some time on coding standards, debugging, unit testing, modularity, and characteristics of good programs. We'll also talk about reading code and what makes a program readable. Can good, readable code replace documentation? How much documentation do you really need?

Third, it's a bit about software engineering, which is usually defined as “the application of engineering principles to the development of software.” What are “engineering principles?” Well, first, all engineering efforts follow a defined process. So we'll be spending a bit of time talking about how you run a software development project and what phases there are to a project. All engineering work has a basis in the application of science and mathematics to real-world problems. So does software development. As I said already, we'll be spending a lot of time examining how to design and implement programs that solve specific problems.

By the way, there's at least one person (besides me) who thinks software development is not an engineering discipline. I'm referring to Alistair Cockburn, and you can read his paper, “The End of Software Engineering and the Start of Economic-Cooperative Gaming” at http://alistair.cockburn.us/The+end+of+software+engineering+and+the+start+of+economic-cooperative+gaming.

Finally, this book is about professional practice, the ethics and the responsibilities of being a software developer, social issues, privacy, how to write secure and robust code, and the like. In short, those fuzzy other things one needs in order to be a professional software developer.

This book covers many of the topics described for the ACM Computing Curricula 2001 course C292c Software Development and Professional Practice (www.acm.org/education/education/curricula-recommendations). It is designed to be both a textbook and a manual for the working professional. Although the chapter order generally follows the standard software development sequence, one can read the chapters independently and out of order. I'm assuming that you already know how to program and that you are conversant with at least one of Java, C, or C++. I'm also assuming you are familiar with basic data structures, including lists, queues, stacks, maps, and trees, along with the algorithms to manipulate them.

I use this book in a junior-level course in software development. It has grown out of the notes I've developed for that class over the past five years. I developed my own notes because I couldn't find a book that covered all the topics I thought were necessary for a course in software development as opposed to one in software engineering. Software engineering books tend to focus more on process and project management than on design and actual development. I wanted to focus on the design and writing of real code rather than on how to run a large project. Before beginning to teach, I spent over 18 years in the computer industry, working for large and small companies, writing software, and managing other people who wrote software. This book is my perspective on what it takes to be a software developer on a small- to medium-sized team and help develop great software.

I hope that by the end of the book you will have a much better idea of what the design of good programs is like, what makes an effective and productive developer, and how to develop larger pieces of software. You'll know a lot more about design issues. You'll have thought about working in a team to deliver a product to a written schedule. You'll begin to understand project management, know some metrics, know how to review work products, and understand configuration management. I'll not cover everything in software development by a long stretch, and we'll only be giving a cursory look at the management side of software engineering, but you'll be in a much better position to visualize, design, implement, and test software of many sizes, either by yourself, or in a team.