Release It! - Introduction

The primary notion that software developers have to embrace is that architectural and design decisions are really financial decisions.  Any time a system is in an unusable state usually means lost revenue.  Software spends most of its life operating in a data center and not in development, so it makes sense to optimize for operations and not development.  Developers are often taught what a system should do, such as make sure the SSN is properly formatted, and not what a system should not do, like running out of memory on constant basis forcing a nightly reboot of the servers.  Most software is designed to pass QA's tests, not survive in the wild for the next 10 years, which often leads to financial impacts. 

The manufacturing domain has the notion of design for manufacturability (DFM) which is the idea of designing products that can be manufactured at low cost with high quality.  Software's idea of DFM might be called design for production.

Decisions made early in a system's development have the most impact on availability, capacity and flexibility.  Unfortunately, the early decisions are often the least informed.  The goal is to make software that is fast and cheap to build, good for users and cheap to operate.  In order to accomplish this, you need to use improved architectural and design techniques.   These techniques need to account for the fact that the scope of software has changed over the years, 25,000 concurrent users and 99.99% uptime on commodity hardware,  instead of a couple hundred users running on mainframes.

Architectures can be split into two groups: Ivory Tower or Pragmatic.  Ivory Tower architectures focus on the end state of the system and are less worried about the messy details.  Ivory Tower architects tend not to listen to coders and probably don't listen to users either.  Ivory Tower architects tend to issue "one size fits all" edicts, such as "you should always code the presentation tier using JSF" or "EJBs should always be used for business logic".  

Pragmatic architectures tend to use lower level abstractions and focus on the dynamic nature of the system.  "How can we update the system without forcing a reboot?" or "How can we make sure the system runs in a lower bandwidth environment?"

Many systems are designed in an artificially clean environment and don't account for real-world settings.  Designers need to reorient their thinking: release 1.0 is not the end of the project but, instead, is the beginning of the software's long life.