Here's an excerpt from the preface to show you what this book is all about:
You've worked hard on the project for more than year. Finally, it looks like all the features are actually complete, and most even have unit tests. You can breathe a sigh of relief. You're done.
Or are you?
Does "feature complete" mean "production ready"? Is your system really ready to be deployed? Can it be run by operations staff, and face the hordes of real world users without you? Are you starting to get that sinking feeling that you'll be faced with late-night emergency phone calls, or pager beeps? It turns out there�s a lot more to development than just getting all the features in.
Too often, project teams aim to pass QA's tests, instead of aiming for life in Production (with a capitol P). That is, the bulk of your work probably focuses on passing testing. But testing---even agile, pragmatic, automated testing---is not enough to prove that software is ready for the real world. The stresses and the strains of the real world, with crazy real users, globe-spanning traffic, and virus-writing mobs from countries you've never even heard of, go well beyond what we could ever hope to test for.
In order to make sure your software is ready for the harsh realities of the real world, you need to be prepared. I'm here to help show you where the problems lie, and what's needed to get around them. But before we begin there are some popular misconceptions we need to discuss.
First, you need to accept that fact that despite your best laid plans, bad things will still happen. It's always good to prevent them when possible, of course. But it can be downright fatal to assume that you've predicted and eliminated all possible bad events. Instead, you want to take action and prevent the ones you can, but make sure that your system as a whole can recover from whatever unanticipated, severe traumas might befall it.
Second, realize that "Release 1.0" is not the end of the development project, but the beginning of the system's life on it's own. The situation is somewhat like having a grown child leave its parents for the first time. You probably don't want your adult child to come and move back in with you, especially with their spouse, four kids, two dogs, and a cockatiel. Similarly, your design decisions made during development will greatly affect your quality of life after Release 1.0. If you fail to design your system for a production environment, your life after release will be filled with "excitement." And not the good kind of excitement, either. We'll take a look at the design tradeoffs that matter, and see how to make them intelligently.
And finally, despite our collective love of technology, nifty new techniques, and cool systems, in the end you have to face the fact that none of that really matters. In the world of business---which is the world that pays us---it all comes down to money. Systems cost money. To make up for that, they have to generate money, either in direct revenue or through cost savings. Extra work costs money, but then again, so does downtime. Inefficient code costs a lot of money, by driving up capital and operations costs. To understand a running system, you have to follow the money. And to stay in business, you need to make money---or at least not lose it.
It is my hope that this book can make a difference, and help you and your organization avoid the huge losses and overspending that typically characterize "enterprise software".
Michael T. Nygard<br /><a href="http://www.michaelnygard.com/" target="_blank" rel="nofollow">http://www.michaelnygard.com/</a><br /> <br />Release It! Design and Deploy Production Ready Software<br /><a href="http://pragmaticprogrammer.com/titles/mnee/index.html" target="_blank" rel="nofollow">http://pragmaticprogrammer.com/titles/mnee/index.html</a>