Introduction

This book contains a collection of essays about software development based on my own experiences. It began as a series of "notes to self" about things I had learned and wanted to remember. The act of writing it down and expanding on the notes forces me to think these things through and increase my own understanding. I also hope that others may find the ideas useful.

This is not a book about writing code. That is, it doesn't contain a catalog of programming tips and tricks that I have discovered. This book does not contain a series of anecdotes about programming either. Books of these types are useful in that they show exactly how another developer solved a specific problem. Of course, if your situation is different, you have to first abstract the principle from the recipe or anecdote in order to gain any advantage.

This book does not describe a formal methodology. There are many books that cover the software development process and attempt to create a reliable, repeatable method of software development. Unfortunately, the methods they describe cannot be applied exactly in any situation. Often, the methodology derives from the programmer's own experience and is colored by the specific situations he encountered. The book becomes a kind of "this worked for me, it will work for you, too." However, in reading many of the books on methodology, I get the feeling that the author is more inclined to theory than actual practice, and I doubt that any real software was ever developed in exactly the way he described.

This book instead attempts to describe what I hope are general principles covering all types of software. The principles are designed to be used in practice and not just theoretical. They are more "This is the way it is" rather than "This is the way it ought to be." I believe it is better to grasp principles that can be applied to a wide variety of situations than to have a set of recipes that may or may not apply to your situation. You can always go back to the principle and derive a good solution to the problem at hand. Thus, to use this information, you will have to understand the principle, analyze your particular situation, and then derive an appropriate process or technique that will work.

No doubt many who read this book will disagree with my principles. That is to be expected, but I hope that reading this will stimulate the reader to think more deeply about software development and at least understand why they disagree. Just saying, "I've never heard of such a thing," or, "That's not what the experts say," is to miss the point of the book. I want people to grasp ideas and know why they believe what they do, and stop just following the recipes that someone else claims is "the only right way to do it."

Although this is my book, I cannot claim that everything in here is original with me. I read a great deal, and ideas from many different sources have merged into my own thoughts to the point that it is difficult to remember who said what, when and where. So if you see ideas that you believe are yours or some other author's, you are probably correct. I just don't have the time or inclination to go back and track down where everything came from. It is also true that many ideas are just "in the air" and are discovered simultaneously by different people. Many of these ideas are the result of day-to-day experience where the solution to a problem was discovered by a group of people working as a team. I can only say, "Thanks to all my friends and fellow software developers."