This book discusses practical software engineering in a simple to read, but useful style. It is only a little over 300 pages, so it isn't a long read and it is well illustrated.

While nothing in the book was earthshattering, it does a very good job of reviewing the basic principles that apply to software projects. It covers a variety of programming practices from code generation to source code control to unit testing. While they aren't discussed in great depth, each one is given a well rounded overview showing what part it plays in a software project and why it is useful.

Most formal education in software construction focuses on the code and not on the processes used to create and manage the code. This book helps focus on the latter. It isn't an all inclusive reference, but it makes a good launching point to decide which tools and practices are worth investing time into learning.

Table of contents:

• A Pragmatic Philosophy -- Programmers must take responsibility for their work and processes. Programmers should actively try to direct their projects toward success. It is important to understand how perfect your code needs to be. You design a one time utility different than you design flight controls for an airplane.
• A Pragmatic Approach -- Basic principles of software design include avoiding duplication and orthogonality (designing in a way that allows for changes with minimal or no side effects). prototypes, iterative rapid development, and matching your programming language to the problem space make problems easier to solve.
• The Basic Tools -- You must become a master of the basic tools used to create software. Keeping information as plain text allows it to be modified easily using unix tools and custom software. Source code control is important not just for your code, but for documentation, configurations, and almost anything else that you have to type into the computer. Code generators save time by allowing you to create code quickly in exactly the same way each time.
• Pragmatic Paranoia -- Don't assume that just because something shouldn't ever happen that it won't ever happen. Assertions and contracts can help test for these conditions and make your code more robust. exceptions are useful, but are often used for "non-exception" situations where normal tests or error checking is more appropriate.
• Bend or Break -- Keeping your software flexible is dependent upon how well you keep your components independent of each other. Metaprogramming allows you to specify information outside of the code, so changes don't require changing the source or recompiling.
• While you are Coding -- Many programmer program by coincidence instead of intentionally. To write good code you must do things on purpose and proactively. Software wizards can save time, but unless you really understand what they are doing, it can come back to haunt you.
• Before the Project -- Most programmers enjoy coding more than getting requirements and specifications. Make sure you have good requirements. It is important to get requirements from the end users and not just their managers. Some problems can't be solved until you've already worked through other parts of the project.
• Pragmatic Projects -- You should consistently test everything in your project. It is much easier to fix a problem when you know what you've changed than three months down the road when you discover something that used to work no longer functions. As much as possible tests should be automated so they run every day. Automate everything you can about your project. This insures that things get done in a consistent manner that can be duplicated.