Principles of CDD

Despite much hype and rhetoric in support of a handful of popular development processes (or methodologies), there are others that are heavily used, and which I encounter very often.

One in particular seems to be almost universally employed -- if not on every project, certainly every organization has used it at one time or another. However, it is not talked about enough as an explicit process, so the core principles and practices are not well known. This, of course, leads to half-measures and partial implementations of the process. To that end, I have gathered what I could find and put it into  a list for your convenience.

Principles of Crisis-Driven Development:
We will remain ever flexible, ready to abandon any principle, decision, deadline, agreement or piece of completed work to satisfy the most current and pressing demands from the customers and users.

• No decision is ever final. Always question the status quo. 
• Live for the day: Today's goals trump yesterday's, or last week's. 
• Competition is to be feared: Any shifts in the market must be addressed immediately to keep the product relevant. 
• Anecdote is critical: Any one bad piece of press, forum post, etc. should be taken to heart, and everything possible done to fix it. 
• No phase or launch is complete: Seek, and expect demand for, constant improvement. 
• Documentation restricts discussion: Avoid it whenever possible. 
• Trust organic knowledge: As long as someone on the team understands a component, it doesn't need to be shared or documented. 
• Reduce administrative overhead: Communicate with the project team only when absolutely needed. 
• Let ideas gain momentum: Raise new concepts, concerns or pitfalls to the group at large only once others are onboard.
• Technical debt can always be paid off: There is a plan to iterate and improve, so short term solutions are fine. It can always be fixed later. 
• Maintainability is a low-priority feature: Add content management or internationalization when you can. 
• Scale when needed: Launch fast and just rebuild storage, software or connectivity when it becomes successful. 

Of course, the same basic ideals apply to Crisis Driven Design, Manufacturing, etc. Whatever your role or phase, any opinion can become a crisis, and any crisis must be met with excitement and anticipation at the opportunity for rework offered to you.

If you have your own versions of these, or additional principles you or your team works off, feel free to share them.