Software engineers are sometimes very, very prone to making things more complex than they need to be. In the engineer's mind, "complex" can be replaced with the word "cool" (or some other amazing adjective). Such a mind has gotten lost, has lost sight of the fact that there exists a most-efficient path from the problem to the solution. Such a predicament is not uncommon -- probably because of something physically wrong in the engineer's mind; And because a certain amount of tinkering is usually required to begin work toward a solution. But, when one becomes enveloped in the problem and forgets about the priority of actually solving the problem, large, unrecognizable apparatus are concocted.

I recently read Release It! by Michael Nygard. I became interested in this book when the NFJS 2008 panel cited it as their #1 suggested read. In my view, the essence of Nygard's expose boils down to two points:

1. One can build software that passes QA with flying colors and still fails miserably in real environments.
2. Problem in production are unavoidable. Good software will be able to navigate them as gracefully as possible.

That said, the book was mostly conceptual, offering real-world examples of how antipatterns in software development made problems that were encountered even worse. Then, he counters with patterns in stability, capacity, general design, and operations. The principles discussed are those that most developers have at least some exposure to, but those that we don't necessarily consider every day. These consist mostly of non-functional requirements that do not often enjoy QA scrutiny. The set of antipatterns and patterns is one that I think all developers, QA, and project managers would do well to consider within the scope of their current and future projects.

Overall, it was a thoughtful book. I particularly enjoyed the sections on capactiy and stability that seemed more immediately applicable to my everday life in code. I found the operations section to be the driest, but giving me opportunity to consider the plight of sys admins. I would agree with the NFJS panel and highly recommend the read.

I have included a short slide deck on the stability section with some highlights on what one might consider and what is explained in much clearer detail in the book.

In software development, be dry, and define data once. But, what if that data needs to be used in many places? This is the case with parts of a web page, for instance, that are common to many different pages. Django has a great mechanism for this: it is context processors.